Summary of Authorize Only issue

["Nelson, David" <dnelson@enterasys.com>]

Let me see if I can summarize the discussion so far, and if folks agree
that I've summarized accurately.

(1) There are three basic SNMP over SSH use cases:

      (a) RADIUS provides initial authentication and 
          base-service authorization of SNMPv3 over
          SSH.

      (b) Some other authentication mechanism/service 
          provides initial authentication (and no
          authorization) of SNMPv3 over SSH.

      (c) Some other authentication mechanism/service 
          provides initial authentication (and no
          authorization) of SNMPv3 over SSH.  RADIUS
          provides base-service authorization of
          SNMPv3 over SSH (but no authentication).

Note that "base-service" authorization means that the SSH server in the
NAS is allowed to provide connectivity via SSH to the SNMPv3 engine of
the NAS.

In case (1a) we require the existing RADIUS authentication methods,
primarily the password authentication, plus some attributes to authorize
the service, such as Service-Type = Framed-Management, and
Framed-Management-Protocol = SNMPv3-over-SSH.

In case (1b) there are no requirements for RADIUS.

In case (1c) we require the ability for RADIUS to provide an Authorize
Only service for SNMP usage.  The provisioning attributes are the same
as for case (1a).

We have seen a considerable amount of discussion on the mailing list of
the issues and properties of an Authorize Only service in RADIUS.  Many
of those discussions focus on potential solutions, but I've restricted
this posting to requirements. 

(2) There are two extended SNMP over SSH use cases:

      (a) RADIUS provides initial authentication and 
          authorization of SNMPv3 over SSH, base-service
          authorization, and (optionally) granular access
          control authorization.

      (b) Some other authentication mechanism/service 
          provides initial authentication (and no
          authorization) of SNMPv3 over SSH.  RADIUS
          provides base-service authorization and 
          (optionally) granular access control
          authorization.

Note that "granular access control" means a mapping to the VACM or some
other Access Control Subsystem.

These use cases are currently out of scope for the ISMS WG charter, but
might be added at a later date.

In case (2a) the additional RADIUS requirement is for an attribute to
authorize granular access control, for example by providing a mapping of
securityName to securityGroup, for use with the VACM.  An example of
such an attribute is Management-Policy-ID, conceptually similar to
Filter-ID.

In case (2b) the additional requirements for RADIUS include those of
case (2a) plus the ability for RADIUS to provide an Authorize Only
service for SNMP usage.

(3) The basic RADIUS trust model dictates that if a NAS, that possess a
valid shared secret with a RADIUS Server, is compromised, nothing in the
RADIUS protocol can mitigate that breach, at least in terms of the
services to which the NAS mediates access.

(4) RADIUS Servers SHOULD exercise appropriate policy enforcement in
terms of providing any NAS with attributes that might disclose security
sensitive information related to a user, e.g. keys, unless that user has
been successfully authenticated to the RADIUS Server via the NAS in
question.  This affects RADIUS Server behavior during any Authorize Only
service provisioning.

In any of the use cases, it is important that the NAS, i.e. the RADIUS
Client, be able to communicate the kind of service being sought via hint
attributes to the RADIUS Server, in the Access-Request message.  This
has implications on the use of the Service-Type in Authorize Only
operations, in which it would otherwise be used as a hint of the
requested service, and not the request authentication method.

It is also important that the RADIUS Server be able to specify the
provisioning of SNMPv3 over SSH service to the NAS in the Access-Accept
message.

Does this accurately summarize the consensus on this issue?  Especially
in terms of requirements that ISMS has of RADEXT?  Please advise, with
suggestions for improvement.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>