Subject: RE: [Isms] FW: RADIUS integration

From: "Nelson, David" <[email-masked]>
Date: Tue, 27 Jun 2006 18:31:52 -0400

Jeffrey Hutzelman writes...

> Except I don't think that's actually a requirement, and
> I do think it makes the solution considerably harder.

Well, I recall a *lot* of discussion early on about ISMS having a
requirement to use *existing* AAA deployments.  There was concern
expressed that if these entrenched systems needed to be updated, that
the ISMS work would never be deployed, and we'd all have wasted our
time.

But, see below...

> I don't consider it unreasonable for people wanting to use
> the authorize-only feature to have to upgrade their
> RADIUS servers to support a new authentication method.

I agree, as long as it's an option.  Unless, of course, we can find a
way to do this using only new attributes that can be enrolled in a data
dictionary.  In that case, no RADIUS server SW upgrade would be
required.

> I do think it is preferable for deployments not using the new feature
not
> to require any changes to the RADIUS server code.

Right.

So, how about this text:

The ISMS WG has a requirement for its use of RADIUS as a centralized AAA
service to be used with SNMPv3 running over a protected transport,
specifically over SSH.  Two operational modes are envisioned.

In the first operational mode, the Access Control Module within the SNMP
engine of the NAS will request of the RADIUS client an authentication of
a remote SNMP user for the purpose of SNMPv3 access over SSH, with
appropriate authorization and provisioning attributes, including those
specific to ISMS usages.  The RADIUS transaction will use an existing
RADIUS authentication method, or possibly use the "Call-Check"
pre-authentication mechanism.

In the second mode of operation Access Control Module in the SNMP engine
of the NAS will request an "Authorize Only" service from the RADIUS
client. The requirement is for an "Authorize Only" service in RADIUS, in
which the NAS asserts the identity of a user, previously authenticated
to the NAS by some other authentication service, such as Kerberos.  The
RADIUS server is required to respond to the NAS with the appropriate
authorization and service provisioning attributes for that user,
including those specific to ISMS usages.

It is desired to leverage existing RADIUS deployments, and thus the ISMS
WG has a preference for RADIUS integration methods that require no
change to RADIUS server implementations, or at most the enrollment of
additional provisioning attributes in a data dictionary.  New RADIUS
operational modes that would require changes to existing RADIUS server
implementations are less desirable, but would be considered for the
"Authorize Only" mode of operation.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 27 Jun 2006 18:43:36 -0400

> pre-authentication mechanism.

This can't and won't happen in the ACM; it needs to happen in the SSH 
layer.  Until a client has successfully authenticated to the SSH server, it 
can't do anything that would be visible to the SNMP engine.

So, what we're really talking about in this scenario is

(1) RADIUS as an authentication backend for SSH
(2) what you called "base-level" authorization to use SNMP
(3) optionally, additional data for fine-grained access control

The data in step (3) would be used by the ACM, though getting it there 
might require a gross violation of modularity in the SNMP engine.  Or, it 
might not.

-- Jeff

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 Jun 2006 10:23:30 +0200

Jeffrey Hutzelman wrote:
> might require a gross violation of modularity in the SNMP engine.  Or,
> it might not.

Two issues:

 - still need to maintain proper functional separation to s/radius/other/
 - how do (2) and (3) interact, if at all?  Are they mutually exclusive
or implementation dependent?

Thanks,

Eliot

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 28 Jun 2006 12:37:46 -0400

>  - still need to maintain proper functional separation to s/radius/other/

Yes.  Conceptually, it's the ssh server that decides whether to allow a 
client to establish a session and/or start SNMP, and it's VACM that decides 
which clients have what level of access to what objects.  These decisions 
can be based partly or entirely on RADIUS, or not.

Part of what we need to to is ensure that it's possible to use RADIUS to 
help make these decisions, even if it isn't used for authentication.

Another part is probably to define a common set of RADIUS attributes that 
can be used to drive these decisions, at least for (2).  I'm not sure if 
that's necessary or appropriate for (3), because I don't have a good idea 
of what kinds of authorization policies people have in place at that level.

> or implementation dependent?

Well, obviously if the answer is (2), you never get to (3). :-)
Otherwise, I don't think they do interact, except that you might do both 
using attributes from the same RADIUS exchange, rather than performing a 
separate query for fine-grained access.

We probably should make it clear in TMSM that an SNMP agent MAY cache 
authorization data (including RADIUS attributes) for the duration of a 
session.  To the extent we talk about RADIUS, we probably want to make it 
clear that while SSH authentication and authorization are distinct and 
separate from VACM, it's OK for an implementation to cache RADIUS responses 
from the former for use in the latter.

Now that I think about it, it seems like it's going to be necessary to have 
some way for the transport mapping to pass some amount of data through to 
VACM, in order to support the case where we don't use the hypothetical 
authorize-only RADIUS mode.  That's either going to be cached RADIUS 
attributes, or some kind of cookie that can be used to make further queries 
to the server.

-- Jeff