Re: [Isms] What granularity of attributes do we need forthe securetransport?

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

Hi,

Let's keep in mind where this thread started. This is NOT about
specifying all sorts of parameters for the security protocols and the
mechanisms that they use. 

This is about what RADIUS specifies as requirements to be met for the
service to be delivered by the NAS.

If I have the relationship between the NAS (RADIUS client) and the
RADIUS server correct, then the NAS asks the RADIUS server how the
service to be provided must be provisioned before providing that
service to the authenticated entity. In the case of the SSHTM, the
service we are looking to have authorized is an SSH subsystem over
which we want to run an SNMP session. It is specifically the SSHTM
that is asking whether an SSH subsystem is authorized for this user. I
don't know how we provide a "hint" that an SSH subsystem is what we
want, without having an attribute to specify that is the protocol we
are interested in running SNMP over. 

If we do not send a hint because there is no attribute for it, then is
it appropriate for RADIUS to **only be able to** respond that "any
transport protocol that provides integrity checking and encryption is
fine for SNMP for this user"? 

dbh

> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On 
> Behalf Of Wes Hardaker
> Sent: Tuesday, April 08, 2008 5:06 PM
> To: Randy Presuhn
> Cc: isms at ietf.org
> Subject: Re: [Isms] What granularity of attributes do we need 
> forthe securetransport?
> 
> >>>>> "RP" == Randy Presuhn <randy_presuhn at mindspring.com> writes:
> 
> RP> But it *also* means that the security administrator setting up
an
> RP> organization's access control policy has to be able to trust
that
> RP> all the "authPrivs" used by that lower layer within that
> RP> organization are sufficiently strong for the information that
the
> RP> access control policy allows to be carried.
> 
> RP> If we don't say how that gets configured, then at least we need
to
> RP> make it known as an operational security consideration.
> 
> Well, let me add the other half of my thoughts...
> 
> It comes back to (as always) required vs optional.  I do 
> think it would
> be beneficial to throw in 100 optional tags that can be used to
supply
> additional configuration for anything (transport security settings
or
> otherwise).  What I think would be wrong is if we required those to
be
> present or the transport couldn't be used.  Having them 
> optional is fine
> since they can be turned off when new features get deployed by SSH
(or
> whatever) that should be used instead.  I should have stated this
> before...
> 
> Ideally I'd want a decoupling of the transport setup 
> parameters as much
> as possible with optional interfaces to be *able to* specify
settings.
> I'd also agree that if they're specified they have to be used (or
the
> transport can't be used if it's impossible...  discarding values in
> security parameters because you don't understand or implement 
> them is a
> recipe for distaster).
> -- 
> Wes Hardaker
> Sparta, Inc.
> _______________________________________________
> 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