Re: [Isms] What granularity of attributes do we need for the secure transport?

["David Harrington" <ietfdbh at comcast.net>]

Hi,

I certainly have never argued that we should provision such things,
except the protocol. 

Question #1: I think the difference in security properties between
TLS, SSH, IPsec, and other "secure transports" are sufficiently large
that an operator might want the ability to say "I approve this service
as long as it is carried over SSH" rather than "I approve this service
as long as it is carried over ANY protocol that provides encryption
and integrity checking". The security considerations for these
protocols might identify environments in which the protocol is not
applicable because of some inherent design issue; for an operator
running an NM protocol in that environment, should they have the
ability to say "gee, my environment has that vulnerability, so I want
to ensure an applicable secure transport is used"?

Question #2: What exactly qualifies as a secure transport? I have
mentioned TLS, SSH, and IPsec even though these are at different
layers. If IEEE 802.1 provides a protocol for integrity checking and
encrypting at layer 2, should I consider that to be sufficient to meet
the integrity-and-confidentiality requirement for RADIUS, even if I
have no transport model prepared to deal with layer 2 protocol
security?

Question #3: In SNMPv3, we made the decision to not try to judge the
strength of security protocols, because it is a constantly moving and
subjective target. We chose instead to accept the
noAuthNopriv/authNoPriv/authPriv requirement and assertion approach.
The proposal to use RADIUS attributes for
integrity-and-confidentiality work roughly the same way. In the SNMPv3
case, we use the authPriv flags in the SNMPv3 message to say these
properties MUST be met; in the RADIUS case, the requirements are
specified in RADIUS attributes. If I understand correctly, in both
cases, it is up to the SNMP security model (now in concert with the
transport model) to ensure the requirements are met, and to assert to
the ACM system that such is the case, without telling the ACM which
protocols or ciphers or ... were used. Are the circumstances with
RADIUS sufficiently different that the require/assert model used for
Community amd USM is no longer adequate?

Question #4: In the Community and USM cases, the auth and priv
services were provided as part of the SNMP engine; now we are
proposing outsourcing those to "secure transports". In USM, it is up
to an operator to configure the user table to specify which auth and
priv protocols/mechanisms are acceptable; in the outsource model, the
operators may need to do that type of configuration in the SSH or TLS
or IPsec configuration. Is this acceptable?

Question #5: In the Community and USM security models, the user table
configuration specified acceptable protocols/mechanisms that are
suitable **for use with the SNMP engine**. In the TSM model, we migth
expect the operators to handle configuration outside SNMP. However,
those same protocols might be used for environments other than SNMP,
so the acceptable mechansisms for SSH general use might be different
than acceptable mechansisms for SSH for SNMP use. Is there really a
difference that operators would want to be able to specify different
requirements for the secure transport configuration, when used with
SNMP (or another NM protocol)?

dbh

> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On 
> Behalf Of Jeffrey Hutzelman
> Sent: Friday, April 04, 2008 10:11 AM
> To: David B. Nelson; isms at ietf.org
> Cc: jhutz at cmu.edu
> Subject: Re: [Isms] What granularity of attributes do we need 
> for the secure transport?
> 
> --On Thursday, April 03, 2008 06:02:19 PM -0400 "David B. Nelson" 
> <dnelson at elbrysnetworks.com> wrote:
> 
> > -- Why do we think that RADIUS authorization should be used 
> to provision
> > specific secure transport properties, such as protocol, 
> cipher suite,
> > authentication mechanism, certificate chains, etc?
> 
> I don't think we think that.  I certainly don't.  And in 
> practice, it can't 
> provision those things, at least for SSH, because they are 
> negotiated well 
> before RADIUS gets involved.  The best an implementation 
> could do is fail 
> authentication if the already-established connection doesn't meet
the 
> requirements described by RADIUS, and really, if you're going 
> to do that, 
> the right solution is to configure the SSH server correctly 
> in the first 
> place so that it negotiates an acceptable connection.
> 
> While it might be useful to centralize management of configuration 
> parameters such as which algorithms the SSH server is willing 
> to support, 
> RADIUS is not the right tool for doing so.
> 
> -- Jeff
> _______________________________________________
> Isms mailing list
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms
> 


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