Subject: RE: [Isms] draft of ISMS charter

From: "Nelson, David" <[email-masked]>
Date: Mon, 22 Aug 2005 11:43:46 -0400

> The other thing to look at is the question where we do the RADIUS
> specific work - whether that actually falls within ISMS (which would
> be logical since ISMS and the RADIUS stuff must work together) or
> whether this actually falls within RADEXT where the RADIUS experts are
> hanging around which we need to review the document. I do not have a
> strong opinion here - perhaps something the IESG should give advise.

Speaking with my RADEXT WG Co-Chair hat on, this work could occur either
in RADEXT or ISMS, but concurrent WG review and concurrent WGLC in both
WGs SHOULD be required.  RADEXT has similar arrangements with other WGs,
such as GEOPRIV.

Dave Nelson

Co-Chair
RADEXT WG

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

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 22 Aug 2005 16:59:43 -0400

I think the definiton of RADIUS attributes for management belongs in
RADEXT.

I think the mapping of securityname to a groupName is an architecural
extensions to the SNMPv3 architecture, and belongs in ISMS, as a
separate architectural extension document with its own MIB module that
is independent of the specific authorization model.
To put this in other words, this is another generic MIB module that
describes how to add authorization to the security subsystem.
 
I think the RADIUS attribute to SNMP groupName mapping is a specific
authorization mechanism, just as AES is a specific encryption
mechanism for the privacy mechanism of the SNMP security subsystem. It
should be described in a separate document, just as the AES-for-SNMP
mechanism is defined in a separate document (RFC 3826). Using a
separate document would permit future designers to add a module for
TACACS+ or authentication mechanisms. The RADIUS attribute mappng may
use the subsytem-common MIB module of the architecural extensions
document, or its own RADIUS-specific MIB module. This is consistent
with the SNMPv3 philosophy of designing subsystems that can be
upgraded/supplemented over time.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Monday, August 22, 2005 11:44 AM
> To: [email-masked]; Juergen Quittek
> Cc: [email-masked]
> Subject: RE: [Isms] draft of ISMS charter
>