Subject: [Isms] FW: [MIB-DOCTORS] FW: Recharter: ISMS

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 10 Jun 2009 10:22:55 +0200

Forwarding comments from David Harrington. A discussion issued on the
AAA-Doctors and MIB-Doctors list. I am not sure how to avoid
cross-posting on four or five lists - probably best is to continue the
discussion on ISMS. 

Dan

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Tuesday, June 09, 2009 10:48 PM
To: Romascanu, Dan (Dan); [email-masked]; [email-masked];
[email-masked]
Cc: 'Pasi Eronen'; 'Juergen Schoenwaelder'
Subject: 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
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, 
> Dan (Dan)
> Sent: Tuesday, June 09, 2009 1:17 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [MIB-DOCTORS] FW: Recharter: ISMS
> 
> Please send me your comments and concerns before Wednesday 6/17. 
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of
> [email-masked]
> Sent: Tuesday, June 09, 2009 10:55 AM
> To: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 10 Jun 2009 08:10:13 -0400

Forwarding to ISMS WG list.

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dave Nelson
> Sent: Wednesday, June 10, 2009 8:04 AM
> To: 'David B Harrington'; 'Romascanu, Dan (Dan)'; [email-masked]; aaa-
> [email-masked]; [email-masked]
> Subject: Re: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS
> 
> David B Harrington writes...
> 
> > The simplest way to approach this problem is to have the
> > RADIUS authorization attributes simply there in the background.
> 
> OK.  This was supposed to be a chartering discussion, but it's turning
> into
> an architecture and design discussion.  Maybe going down that path for a
> moment will help resolve the charter text issue. I'm not sure.
> 
> So, how do systems typically use RADIUS?  Well, you have a device to which
> network connections can be made, that is sessions established and service
> provided.  There is some gatekeeper function that moderates access.  That
> gatekeeper function can call the RADIUS client module and ask the "Mother,
> may I?" question on behalf of the user identity associated with the
> connection attempt.  RADIUS comes back with a "Yes" or a "No" and perhaps
> some modifiers or limitations.  The result of that consultation with
> RADIUS
> does indeed exist in the background.  The gatekeeper function typically
> keeps it as part of some session state.  Or maybe not.  It depends on
> what's
> needed.
> 
> The key point here is that the gatekeeper function calls the RADIUS client
> function to ask an access control question.  The RADIUS client, after
> talking to the RADIUS server, provided an answer.  Typically this happens
> only once at the point of session establishment.  For scalability and
> efficiency reasons, it can't happen for every discrete operation.
> 
> All of that comports with the notion that the RADIUS attributes exist in
> the
> background.  What is not accounted for is that doesn't happen by magic.
> Something has to call on RADIUS to request that information, and if that
> something isn't the Access Control Model, what is it?
> 
> > My concern is maintaining the modularity that was deliberately created
> > by the SNMPv3 WG to allow modular extensibility. This is all about
> > separating who knows what. RADIUS knows about authorization
> > attributes, not about VACM.
> 
> The RADIUS client does not know about VACM.  VACM is simply a module (yes
> I
> mean that, a piece of code) that calls the RADIUS client's API.  The
> RADIUS
> client (asynchronously) calls back with the results of the authentication
> /
> authorization request.  The RADIUS client doesn't know what VACM (the VACM
> extension) is going to do with this the information.  As a matter of
> practicality, the VACM extension will probably dynamically update one of
> its
> MIB modules with the information obtained from RADIUS.  That information
> will exist for the duration of the "session".  Probably the hardest thing
> about this work will be for the VACM extension to figure out when the
> "session" is over and when to flush the temporary information from its MIB
> module.  We've encountered this issue already.
> 
> > When the charter says that RADIUS provides VACM username-to-groupname
> > dynamic provisioning, that is wrong. RADIUS provides a policy name.
> 
> Pedantically, you're correct.  The RADIUS client provides the VACM
> extension
> with a policy name that's bound to a username and the VACM extension uses
> that information to populate the MIB table.
> 
> 
> OPS-DIR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-dir