Subject: RE: [Isms] draft of ISMS charter

From: Juergen Quittek <[email-masked]>
Date: Mon, 22 Aug 2005 22:45:21 +0200

David,

I am fine with both ways, having such a document either
as ISMS or as RADEXT WG document.

The ISMS charter can be shaped to include it.
After reading the RADEXT charter I am not sure what would
be the procedure for establishing the document as RADEXT
work item.

What does your arrangement with GEOPRIV look like?

Anyway, I fully agree with you that such a document should
receive extensive guidance and reviews from both WGs.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

--On 8/22/2005 11:50 AM -0400 Nelson, David wrote:

>> 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 as an individual and co-author of a relevant I-D, I would like
> to point out that we have a draft under consideration in RADEXT that
> currently includes this functionality.
>
> http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho
> rization-02.txt
>
>

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

---

From: "Nelson, David" <[email-masked]>
Date: Mon, 22 Aug 2005 16:04:03 -0400

Juergen,

> as ISMS or as RADEXT WG document.

If it is a very simple document (one or two attributes) it may be better
to include it in a related RADIUS document, but that is not a major
decision point.

> be the procedure for establishing the document as RADEXT

A formal request from ISMS would likely be all that is required.  This
work is not going to be making any extensions to RADIUS that would raise
charter flags on the basis of RADIUS backwards compatibility or Diameter
forwards compatibility issues.

The document that I have co-authored with Greg Weber should be ready for
consideration as a RADEXT WG document once the needs of ISMS have been
clarified.  It is our intent to submit it as a WG work item.

> What does your arrangement with GEOPRIV look like?

The document is chartered in GEOPRIV and we are providing concurrent
review.

We are also chartered to work on documents in RADEXT that have been
requested through liaison letters from other SDOs, such as 3GPP, 3GPP2,
WiFi Alliance, WiMAX, etc.

> receive extensive guidance and reviews from both WGs.

Yes.  Thanks!

-- Dave

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 24 Aug 2005 19:19:33 +0200

David (Nelson),

--On 8/22/2005 10:59 PM +0200 David B Harrington wrote:

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

I also would prefer this option.
Do you think we should bring the issue to the RADEXT mailing list?

Thanks,

    Juergen

> 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
>>
>> 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
>>

---

From: "Nelson, David" <[email-masked]>
Date: Wed, 24 Aug 2005 13:44:21 -0400

Juergen Quittek writes...

(Cross posted to RADEXT and ISMS WG lists)

> Do you think we should bring the issue to the RADEXT mailing list?

Yes.

As I have already indicated, we have an existing draft under
consideration in RADEXT that contains this type of new attribute.  It is
fairly close to being ready for adoption as a WG work item.  We could
use this existing draft, or we could break it out as separate draft.

I think the important things for ISMS to communicate to RADEXT are:

(a) That ISMS has a requirement for standardization of a RADIUS
attribute for the purpose of providing authorization of SNMPv3 access to
the NAS (managed entity) via the ISMS mechanisms (i.e. SSH, etc.).

(b) That the attribute will be used in the ISMS security method to map
into one or more SNMP security parameters, such as securityName or
groupName.

(c) The desired milestone date for sending such an I-D to the IESG for
approval, that aligns with the ISMS WG milestones.

Since, I've already cross posted this message to RADEXT, we can use this
as the starting point for discussions.