[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIB-DOCTORS] FW: Recharter: ISMS
Hi,
1)
I support this work.
I believe the RADIUS support for SNMPv3 authorization is important.
I will not be able to participate actively in this work,
unfortunately.
2)
I think the charter is misworded.
"obtaining VACM authorization information via RADIUS" seems to violate
the modularity of the RFC3411 architecture.
There should be two steps.
1) obtaining authorization information via RADIUS, using "Remote
Authentication Dial-In User Service (RADIUS) Authorization for Network
Access Server (NAS) Management". The authorization information should
be in an access model independent form, so it can be used with
different access control models.
2) applying the RADIUS authorization information to the view-based
access control model.
I suggest rewording this to read
"Applying RADIUS Management Authorization attributes to the view-based
access control model (VACM)."
3)
I think this wording is slightly wrong:
"The authorization information will be limited to mapping the
authenticated principal to existing access control polices ..."
I think the RADIUS authorization could potentially reference policies
that do not exist on the managed device yet. I recommend:
"The authorization information will be limited to mapping the
authenticated principal to access control policies ..."
(I personally prefer "named access control policies" or "access
control policy names", but that's a nit.)
The WG will need to decide whether to install the unrecognized policy
as a new policy (groupname) even though it may not be supported by
preconfigured group access rights, or to discard the RADIUS
authorization attributes for a policy that is not supported locally.
RADIUS should NOT need to know whether the corresponding access rights
are provisioned on the managed entity.
If user/groupname bindings can be installed dynamically, even though
the policy (group access) is not provisioned, a new access control
model or extension or an implementation might go get the values to
dynamically provision the policy details automatically, rather than
requiring operators to preconfigure the access rights for groups who
may never actually need to manage the device.
4)
a continuation of point 2)
> - Specify a mechanism to support centralization of SNMPv3 Access
> Control decisions by means of a RADIUS-provisioned
> username-to-groupname dynamic mapping, that would provide
> a binding
> between a user and preconfigured VACM policies via
> dynamic additions
> to the securityToGroupname table. Additionally, specify a
> time limit
> for access decisions, and such a time limit should be used to
> garbage collect expired dynamic securityToGroup mappings.
I think it is important to recognize that the SNMPv3 WG deliberately
made the binding mechanism between a principal and the AC policy the
responsibility of the specific AC model. Another AC model might use a
different binding mechanism to bind the principal and the
RADIUS-provisioned policy name.
RADIUS should supply a model-independent policy name, with no RADIUS
knowledge of how the binding will occur within an AC model.
The VACM extension should apply that RADIUS-provisioned policy name to
the authenticated identity using the VACM-specific
username-to-groupname mapping table.
RADIUS should supply a time limit for the named policy; However, it is
the VACM extension that understands this will be enforced by
garbage-collecting expired entries in the username-to-groupname table.
A different access control model might enforce the time limit for the
named policy by using different AC mechanisms.
5) should we be saying AAA rather than RADIUS?
6) in the milestones, should "centralized access" be "VACM extension"?
The RADIUS management authorization document already defines the
"centralized access" mechanism. ISMS just needs to write the VACM
extension to utilize the RADIUS authorization attributes.
7)
Should the charter include updating the SNMP-VIEW-BASED-ACM-MIB, if
needed?
A new MODULE-COMPLIANCE may need to be written.
David Harrington
dbharrington at comcast.net
ietfdbh at comcast.net
dharrington at huawei.com
> -----Original Message-----
> From: mib-doctors-bounces at ietf.org
> [mailto:mib-doctors-bounces at ietf.org] On Behalf Of Romascanu,
> Dan (Dan)
> Sent: Tuesday, June 09, 2009 1:17 PM
> To: ops-dir at ietf.org; aaa-doctors at ietf.org; mib-doctors at ietf.org
> Subject: [MIB-DOCTORS] FW: Recharter: ISMS
>
> Please send me your comments and concerns before Wednesday 6/17.
>
> Thanks and Regards,
>
> Dan
>
>
> -----Original Message-----
> From: iesg-bounces at ietf.org [mailto:iesg-bounces at ietf.org] On
> Behalf Of
> Pasi.Eronen at nokia.com
> Sent: Tuesday, June 09, 2009 10:55 AM
> To: iesg at ietf.org
> Subject: Recharter: ISMS
>
> [Secretariat (Bcc'd), please place this on 2009-06-18 agenda for
IETF
> review, and send out an internal review announcement]
>
> ISMS WG has completed its major deliverables for securing
> SNMP with SSH,
> and is planning to take on new work: obtaining VACM authorization
> information via RADIUS, and specifying TLS/DTLS based transport for
> SNMP. The proposed charter text is included below.
>
> Tim and I are still looking for a co-chair (Juergen Schoenwaelder
has
> indicated that he cannot continue as the only chair, and will not be
> able to attend IETF76 and IETF77), but let's review the contents
while
> Tim and I look for someone...
>
> Best regards,
> Pasi
>
>
---------------------------------------------------------------------
>
> Integrated Security Model for SNMP (isms)
>
> Description of Working Group:
>
> The Simple Network Management Protocol version 3 (SNMPv3) provides
> message security services through the security subsystem.
Previously
> the ISMS Working Group defined a Transport Subsystem definition, a
new
> Transport Security Model, and a Secure Shell Transport Model and a
> method for authenticating SNMPv3 users via the Remote Authentication
> Dial-In User Service (RADIUS). The initial body of work to be
tackled
> by the working group involved only these pieces. Additional work on
> other transport models and other security extensions were to
> wait until
> the initial transport architecture and defining documents were
> completed.
>
> It is now possible to authenticate SNMPv3 messages via a RADIUS when
> those messages are sent over the newly defined SSH transport.
> However, it still remains impossible to centrally authorize a
> given SNMP
> transaction as on-device pre-existing authorization configuration is
> still required. In order to leverage a centralized RADIUS service
to
> its full extent, the access control decision in the Access Control
> Subsystem needs to be based on authorization information received
from
> RADIUS as well. The result will be an extension to the View-based
> Access Control Model (VACM), to obtain authorization
> information for an
> authenticated principal from RADIUS. The authorization
> information will
> be limited to mapping the authenticated principal to existing access
> control polices, defining session timeouts, and similar session
> parameters. This mechanism will not provision the detailed access
> control rules.
>
> Additionally, new work will be undertaken to define TLS and
DTLS-based
> transports that can offer support for environments that prefer
> certificate authentication. Certificate based authentication is
> desirable for many environments with a centralized authentication
> service. DTLS also provides datagram-based transmissions which may
be
> desired for environments where TCP performance suffers because of
> network anomalies (e.g. high packet loss rates). A combination of
TLS
> and DTLS-based transports offers solutions that addresses
> both the need
> for certificate-based authentication and for datagram-based
delivery.
> Operators will be able to chose the transport solution that best
meets
> their needs.
>
> The current goal of the ISMS working group is two-fold: to develop a
> method for allowing for access control decisions to be based on
> information provide by an AAA provisioning service and to develop
> TLS-based and DTLS-based Transport Models.
>
> The new work must not modify any other aspects of SNMPv3 protocol as
> defined in STD 62 (e.g., it must not create new PDU types).
>
> The working group will cover the following work items:
>
> - Specify a mechanism to support centralization of SNMPv3 Access
> Control decisions by means of a RADIUS-provisioned
> username-to-groupname dynamic mapping, that would provide
> a binding
> between a user and preconfigured VACM policies via
> dynamic additions
> to the securityToGroupname table. Additionally, specify a
> time limit
> for access decisions, and such a time limit should be used to
> garbage collect expired dynamic securityToGroup mappings.
>
> - Specify TLS and DTLS transport models for SNMP.
>
> Goals and Milestones:
>
> Jul 2009 Publish initial documentation on the (D)TLS
> transports for SNMP
> Jul 2009 Publish initial documentation for the centralized access
> control Jan 2010 Submit documentation on the (D)TLS
> transports for SNMP
> to IESG Jan 2010 Submit documentation for the centralized
> access control
> to IESG
>
>
---------------------------------------------------------------------
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS at ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors
>