Subject: [Isms] RADIUS/VACM - normative reference to RFC 5591?

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 6 Mar 2010 11:59:26 -0800

Hi -

There is one other issue that I think needs to be brought
to the WG's attention.  Even if we decide to do nothing
about it, I think the decision should be a conscious one.

Issue:
   3.  Does the reference to RFC 5591 need to be normative?

One of the surprising things about the evolution of the
RADIUS/VACM integration is that all the references to
RFC 5591 come very close to being "for examples", rather
than clear normative references.  This is a consequence
of our decision to describe this integration in a way
that would permit its use with other transports / security
models.  Indeed, even the title has become somewhat misleading,
since RADIUS is just one example of an AAA service that
could be supported.

On the other hand, the document DOES spell out exactly which
RADIUS attributes are to be used, and just "hand waves" what
would be used with other AAA services.

Do we want / need to do anything about this?

Randy

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Mar 2010 09:00:02 -0500

Resending from my enrolled email address.

> On Mar 6, 2010, at 2:59 PM, Randy Presuhn wrote:
>
>> models.
> I'm a little less optimistic about our ability to "future-proof"  
> this document, in the traditional fashion of the strongly modular  
> SNMP architecture.  It's quite possible that some other transport  
> and security models could be used with AAA-provisioned access.  On  
> the other hand, given the poor modularity properties of the original  
> Security Subsystem architecture, which really only supports locally- 
> based models such as USM, I would prefer to avoid making overly  
> general statements, in the absence of time to think out the relevant  
> details and specific text to review.
>
>> Indeed, even the title has become somewhat misleading,
> Um...  Well, I'm only aware of RADIUS, Diameter and TACACS as  
> potential AAA candidates.  Diameter inherits RADIUS attributes via  
> its NAS Application, so that leaves only TACACS unconsidered.  For  
> the reasons articulated above, I would hesitate to make overly  
> general assertions that might come back to haunt us, when someone  
> actually tries to undertake a particular extension of this work.
>
> Regards,
>
> Dave
>
> David B. Nelson
>
> Elbrys Networks, Inc.
> 282 Corporate Drive, Unit 1
> Portsmouth, NH 03801
>
> +1.603.570.2636
> www.elbrys.com
> [email-masked]

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Mar 2010 08:57:07 -0500

> that would permit its use with other transports / security

I'm a little less optimistic about our ability to "future-proof" this  
document, in the traditional fashion of the strongly modular SNMP  
architecture.  It's quite possible that some other transport and  
security models could be used with AAA-provisioned access.  On the  
other hand, given the poor modularity properties of the original  
Security Subsystem architecture, which really only supports locally- 
based models such as USM, I would prefer to avoid making overly  
general statements, in the absence of time to think out the relevant  
details and specific text to review.

Um...  Well, I'm only aware of RADIUS, Diameter and TACACS as  
potential AAA candidates.  Diameter inherits RADIUS attributes via its  
NAS Application, so that leaves only TACACS unconsidered.  For the  
reasons articulated above, I would hesitate to make overly general  
assertions that might come back to haunt us, when someone actually  
tries to undertake a particular extension of this work.

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrys.com
[email-masked]