Subject: [Isms] FW: RADIUS integration

From: "David B Harrington" <[email-masked]>
Date: Fri, 23 Jun 2006 17:52:44 -0400

FYI.

-----Original Message-----
From: David Harrington [mailto:[email-masked]] 
Sent: Thursday, March 16, 2006 7:50 PM
To: 'Kaushik Narayan (kaushik)'; 'Nelson, David';
[email-masked]
Cc: 'Juergen Quittek'; 'Joseph Salowey (jsalowey)'
Subject: RADIUS integration

Hi,

A private question came up about the RADIUS integration that was
discussed at the interim. Since others may have different
recollections, and many in the WG may not understand from the minutes
what was discussed, I want to provide an overview of the
interim-recommended approach on the mailing list.

Q: Should the RADIUS integration be specific to SSHSM or can it apply
to all transport-mapping security models?

My understanding of the architectural positioning of the RADIUS piece
that we discussed during the interim is that it is independent of the
protocol used to provide authentication. The SNMP engine says to the
RADIUS server "I assert that this principal has already been
authenticated by other means. Please tell us what he is authorized to
do." Obviously, the RADIUS server must trust the snmp engine as
authentic. Effectively, this is a new authentication "mechanism" for
RADIUS.

The reason this was discussed is that many administrators prefer to
use Kerberos or other authentication mechanisms, while still using
RADIUS (or other service) to determine the authorizations for a
principal. This separation of authentication and authorization is an
important principal in SNMPv3. SNMPv2 bound them together, but the
SNMPv3 WG separated them and provided securityName as the
model-independent binding.

The discussions at the interim placed the RADIUS (or other)
authorization mechanism as an optional piece in an Access control
model (or maybe the access control subsystem). It should have no
dependencies on or place any dependencies on modules in the
applications, the dispatcher, the messaging subsystem, the security
subsystem, or the transport mapping, other than the model-independent
parameters (e.g. securityName) that flow between subsystems through
the ASIs.

Therefore, it would be inappropriate to develop a RADIUS integration
with SSHSM, or even with TMSM, since it should also work when USM or a
Kerberos security model provides the "already authenticated
principal".

David Harrington
[email-masked] 

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

---

From: "Nelson, David" <[email-masked]>
Date: Fri, 23 Jun 2006 18:38:43 -0400

David Harrington writes...

> The SNMP engine says to the
> do." 

One of the things that the RADIUS server might very likely want to tell
the SNMP engine is whether or not the authenticated user is allowed to
manage devices using SNMP.  If the answer is "no" then the established
session gets dropped.  With USM, the act of authenticating the user via
the local USM data store implicitly authorizes the user to use SNMPv3.
We don't know what access control would be applied, of course.  In that
regard, authorization of access controls would be similar in USM and
TMSM.

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 27 Jun 2006 13:53:46 -0400

Jeffrey Hutzelman writes...

> I suspect we're reaching the point where we should take 
> this discussion out of ISMS and over to RADEXT instead.

I think that would be useful.  I've "penciled-in" a discussion slot in
the RADEXT WG session at IETF-66.  The agenda is always quite full, so
it would be really helpful to get some discussion going on the list
prior to Montreal.