Subject: RE: [Isms] FW: RADIUS integration

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

David Harrington writes...
 
> FYI.

I've forgotten how I replied to the original message.
 
> Q: Should the RADIUS integration be specific to SSHSM or can it apply
> to all transport-mapping security models?

It is possible that it could apply to all transport-mapping security
models, but it would take some additional analysis to be sure.
 
> 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.

That was the expressed preference.  It has not been determined that
RADIUS can (should) be used in that fashion. That is the subject of
ongoing study.  Today, RADIUS is defined to provide separate
authorization services only when the original authentication was via
RADIUS and the RADIUS client and server share a state cookie.

> 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 trust model is one issue and the new authentication mechanism is a
second issue.  Given the desire to re-use existing RADIUS infrastructure
to a large extent, the changes to RADIUS severs should be limited to new
attributes that could be enrolled in a data dictionary.

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

Yes.

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

Nice sentiment.  It would be helpful if ISMS would formalize this
requirement for a new RADIUS "null" authentication mechanism, using an
asserted identity and the trust relationship between the RADIUS client
and server, together with an "authorize only" type of service request,
in a formal document to the RADEXT WG.  This is an action item out of
the Boston Interim Meeting, as I recall.  I did not undertake this
action item, because of my position as a co-chair of RADEXT.  I think
that the requirement should come from the ISMS WG chairs.  

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

We might be able to do this.  If you want to maintain the full degree of
modularity you will need to, but there is some considerable work to do
on the RADIUS side to achieve this goal.  I think we have a trade off to
make between re-using existing AAA infrastructures and maintaining the
traditional level of modularity and functional independence of SNMP.

While there are undoubtedly a number of customers that want to use one
service for authentication and another service for authorization, it is
not clear to me that the original survey respondents who asked for
integration with RADIUS had this in mind.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Jun 2006 17:07:56 -0400

> RADIUS and the RADIUS client and server share a state cookie.

And that model is no longer sufficient.  Authentication and authorization 
_are_ separate concepts, and people are beginning to recognize that and 
treat them separately.  Authentication is no longer always about usernames 
and passwords, and some authentication methods do not lend themselves to 
authenticating to some entity other than the one you want to talk to. 
Whether it's SSHSM, an SSH login session, 802.1x, or PPP dialup, 
authentication may take place via a mechanism that is outside the RADIUS 
server's control.  Once that happens, the application needs to make a 
decision as to whether to provide access and at what level, and RADIUS is 
an appropriate tool for that, even though it did not handle authentication. 
But it can only be used that way if a RADIUS client can say "this is the 
user's identity; tell me what I need to know to make an access decision".

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Jun 2006 17:17:12 -0400

> integration with RADIUS had this in mind.

It is worth noting here that the entire motivation behind ISMS is allowing 
sites to reuse their existing authentication infrastructure with SNMP.  I 
don't know who originally requested this feature or why, but I can tell you 
that as a site which has been using Kerberos authentication for nearly 15 
years, we are uninterested in authorization schemes that don't work with 
Kerberos authentication.  My dialup NAS's have used Kerberos authentication 
since late 1999, and they use TACACS+ for access control because RADIUS 
couldn't do what we needed, which was to provide access control and 
provisioning without being responsible for authentication.

-- Jeff