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

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

Hi,

I want to make sure my choice of wording doesn't mislead.

When I say "the NAS asks the RADIUS server how the service to be
provided must be provisioned", I do NOT mean the RADIUS server
provides provisioning information or tells the NAS how to subsequently
provision the service.

The RADIUS server says to the NAS "if your configuration of the
service meets these requirements, then you can deliver the service to
this user; if your configuration does not meet these requirements,
then you MUST NOT deliver this service to this user".
--

I am trying to understand where the responsibilities lie, to see if
there is  enough information to make the determination. Let me lapse
in COPS-PR terminology, and think of RADIUS in terms of a policy
decision point (PDP) at the RADIUS server and a policy enforcement
point (PEP) at the NAS. So the RADIUS server must be configured to act
as the policy decision point, while the NAS must be configured to act
as the policy enforcement point. RADIUS only tells us the operators'
policy for the service for the authenticated user; the NAS enforces
the policy.

Operators have the responsibility to configure the RADIUS server to
specify the policy for "service to this user", and to configure the
security available on the NAS to enforce the policy. 

--
Let's first consider whether the NAS can enforce the RADIUS policy:

The SNMP transport/security models have the responsibility to
determine whether the transport meets the SNMP authPriv requirements.
If RADIUS sends an access-accept, then we know we have auth. If the
RADIUS policy says "integrity+confidentiality", the transport/security
model must check the transport to see if priv is provided. If it is
not, then we must treat this as an access-reject.

Actually, the SNMP engine doesn't check this; we trust that the
transport provides it if we request it in securityLevel for an
outgoing message, and for incoming we trust authPriv is provided if
tmStateReference says it is. But, we implicitly trust the transport
layer because SNMP has no capability to verify the requirement sent in
the  RADIUS policy (so in SSHTM we fill in tmStateReference with a
hard-coded value).

This raises the question of whether it is appropriate for us to design
a solution where RADIUS says "you MUST verify that the service meets
these requirements" and then gives us a requirement we know we cannot
check (because SNMP should not know any of the details of transport
security). So should RADIUS even send this transport-protection policy
to SNMP at runtime if we know SNMP cannot enforce this at runtime?

Realistically, we don't need this attribute in RADIUS if all NM
protocols will be expected to be similarly unable to *verify* how the
security has been configured, because they also should have no
knowledge of security configuration details. Right?

Consistency of security properties across management interfaces is
important to have holistic security. If other NM protocols, like the
CLI, are expected to be able to actually verify the security
configuration, then so should SNMP. And then it would make sense to
have the transport-protection RADIUS attribute. If RADIUS can require,
and other NM protocols can verify, other aspects of security
configuration, then SNMP should also be able to verify those details. 

If RADIUS will specify requirements for the service, we MUST be able
to verify we do meet the requirements.

dbh


> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:j.schoenwaelder at jacobs-university.de] 
> Sent: Wednesday, April 09, 2008 9:34 AM
> To: David Harrington
> Cc: 'Wes Hardaker'; 'Randy Presuhn'; isms at ietf.org
> Subject: Re: [Isms] What granularity of attributes do we need 
> forthesecuretransport?
> 
> On Tue, Apr 08, 2008 at 07:23:58PM -0400, David Harrington wrote:
>  
> > 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. 
> 
> I think this thinking is backwards. RADIUS is not a provisioning
> protocol as far as I can tell.
> 
> Since the secure transport already exists when RADIUS comes into
play,
> all we can reasonably do is ship information about the actual secure
> transport to the RADIUS server so that the RADIUS server can take
this
> into account when it takes a decision.
> 
> Radius experts, please correct me if I got this wrong.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> 


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