Subject: [Isms] Summary of Authorize Only issue

From: "Nelson, David" <[email-masked]>
Date: Wed, 26 Jul 2006 15:56:04 -0400

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.

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 26 Jul 2006 13:12:46 -0700

>question.  This affects RADIUS Server behavior during any Authorize Only

For this to be successful, the RADIUS server needs to know what service is 
being requested by the NAS, so that it can limit the attributes to those 
relevant to that service (or refuse to authorize the service).  The service 
cannot be characterized by saying it is "authorize-only" --  that is merely 
a particular (authorize-only) mode of a particular service which needs to be 
specified by the NAS.

>attributes to the RADIUS Server, in the Access-Request message.

Service-Type is not a "hint".  A RADIUS client that receives an 
Access-Accept with an unknown Service-Type does not treat the attribute as a 
"hint" -- it treats it as an Access-Reject.  This is mandatory behavior in 
RFC 2865.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 26 Jul 2006 22:31:05 -0400

Hi,

Comments inline. 

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Wednesday, July 26, 2006 3:56 PM
> To: [email-masked]; [email-masked]
> Subject: [Isms] Summary of Authorize Only issue
> 

I think "SNMP over SSH" would be appropriate. I do not see a reason to
limit it to SNMPv3.
While only SNMPv3 is beig fitted to the SSH transport today, other
versions of SNMP could be supported in the future. The message version
should not make a difference.

>           authorization) of SNMPv3 over SSH.

Whether the other services provides authorization or not is
immaterial.

>           SNMPv3 over SSH (but no authentication).

I'm not sure anybody has asked for this combination, but I suppose we
don't need to rule it out.

> NAS is allowed to provide connectivity via SSH to the SNMPv3 engine
of

I would like to make sure everybody understands that the NAS is the
managed device, not only edge devices providing network access
services; Every SNMP-manageable device in the network might be
considered a NAS in this scenario.

> Framed-Management-Protocol = SNMPv3-over-SSH.

Educate me. Why primarily the password authentication? Does this imply
a (plaintext) password?
I think that might be undesirable if it requires the pass-through of a
human interaction, or storage of a password at the management
application or the managed system. It is highly likely the "user"
might be a management application like HP OpenView or Spectrum, rather
than a user working with snmp command line tools. Other authentication
mechanisms might be preferable to passwords; I assume RADIUS supports
a wide range of authentication mechanisms.

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

I think there are three extended SNMP use cases that involve RADIUS
>           (optionally) granular access control

	  (c) RADIUS does not perform authentication or 
            base-service authorization.
            Some other authentication mechanism/service 
            provides initial authentication and presumably
            base service authorization for SNMP over whatever 
            secure transport, such as SNMP using USM over UDP,
            or SNMP using USM and TCP/IPv6, or SNMP using Kerberos
            and SCTP, or SNMP using 802.1AE and Ethernet.
            The access control subsystem requests from RADIUS
            ONLY the granular access control authorization
            associated with the otherwise-authenticated user.
		(e.g., hey RADIUS, which group is this guy in?)
		
> might be added at a later date.

Yes. I think demand for this is high and should definitely be added at
a later date.

> case (2a) plus the ability for RADIUS to provide an Authorize Only

In case (2c) the ONLY requirement for the RADIUS server is to provide
to
the trusted RADIUS client an attribute such as a Management-Policy-ID,

for a user identity that was authenticated and base-authorized by some

other service.

> question.  This affects RADIUS Server behavior during any 

Who sets the policy the RADIUS server will enforce? 
i.e., how does the RADIUS server know which attributes contain
security-sensitive information related to a user?

> attributes to the RADIUS Server, in the Access-Request message.
This

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 26 Jul 2006 19:51:20 -0700

>           SNMPv3 over SSH (but no authentication).

David> I'm not sure anybody has asked for this combination, but I suppose we
David> don't need to rule it out.

That's useful for ssh public-key authentication with RADIUS
auto-authorization configuration.
-- 
Wes Hardaker
Sparta, Inc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Jul 2006 10:03:47 +0200

> might be added at a later date.

Note that the reference "these use cases" is somewhat ambiguous. I
assume you refer to (2a) and (2b). But even with this interpretation,
it is only the optional part which is out of scope for the ISMS WG.

Personally, I consider provisioning of SNMP access control mappings
via RADIUS authorization a functionality which is totally independent
of authentication and base-service authorization. So perhaps (2a) and
(2b) should be combined into an SNMP access control provisioning use
case:

(2) There is an SNMP access control provisioning use case:

    RADIUS provides authorization information to be used by SNMP
    access control models, 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. Due to the strict separation of access control from
    authentication in the SNMP architecture, this requires that RADIUS
    provides an Authorize Only service for SNMP usage.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany