From bernard_aboba@hotmail.com Wed Jun 3 02:38:05 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21953A6B41 for ; Wed, 3 Jun 2009 02:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[AWL=1.980, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnpivqU3cP0O for ; Wed, 3 Jun 2009 02:38:03 -0700 (PDT) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by core3.amsl.com (Postfix) with ESMTP id 7F33B3A6862 for ; Wed, 3 Jun 2009 02:38:02 -0700 (PDT) Received: from BLU137-W3 ([65.55.111.73]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 02:38:04 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_cbccff4c-82f2-41b1-bbaf-a0440d791d25_" X-Originating-IP: [97.120.166.87] From: Bernard Aboba To: Alan DeKok , , , Date: Wed, 3 Jun 2009 02:38:04 -0700 Importance: Normal In-Reply-To: <4A20E0BC.2080301@deployingradius.com> References: <4A20E0BC.2080301@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2009 09:38:04.0474 (UTC) FILETIME=[FE69B9A0:01C9E42E] Subject: Re: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 09:38:05 -0000 --_cbccff4c-82f2-41b1-bbaf-a0440d791d25_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are also some pretty nasty effects on multi-homed hosts who may send= DNS queries on multiple interfaces=2C including the "WiFi hotspot" interface.=20 This can result in a user who has a perfectly serviceable alternative conne= ction (e.g. Ethernet=2C HSDPA=2C etc.) being unable to resolve names because their WiFi hotspot has decided to (qu= ickly) return a synthesized (bogus)=20 answer to every query.=20 The load of support calls this can create is so large that the practice of = forbidding multi-homing (via use of suitably configured connection managers) has become quite common place. =20 > Date: Sat=2C 30 May 2009 09:31:08 +0200 > From: aland@deployingradius.com > To: secdir-secretary@mit.edu=3B raft-ietf-dnsext-dnsproxy.all@tools.ietf.= org=3B aaa-doctors@ietf.org > Subject: [AAA-DOCTORS] Secdir review of draft-ietf-dnsext-dnsproxy-05 >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > Over all=2C the document appears to be clear. >=20 >=20 > I wonder about the following text in section 4.5=2C however: >=20 > NB: any DNS proxy (such as those commonly found in WiFi hotspot > "walled gardens") which transparently intercepts all DNS queries=2C an= d > which returns unsigned responses to signed queries=2C will also cause > TSIG authentication failures. >=20 >=20 > The problem with WiFi hotspot DNS proxies is much=2C much=2C worse than > this simple paragraph would suggest. There are issues found in in those > deployments that are not discussed in this document. I will summarize > them here: >=20 >=20 > Issue: responding to all DNS requests with the IP of the hotspot >=20 > Goal: to guide all client traffic to the hotspot >=20 > Background: Many client machines have VPN software that checks for the > existence of "internal" corporate DNS names. If the names resolve=2C the > client is assumed to be "within" the corporate network. If the name > does not resolve=2C the client is assumed to be elsewhere=2C and the VPN > software behaves differently. DNS proxies that return an answer for all > names result in the client erroneously believing it is in the "internal" > network. Various things then fail in weird and wonderful ways. >=20 > Even when VPN software doesn't exist=2C this practice can cause other > problems. A commonly used web browser (I.E. from a major vendor) can > cache the results of DNS queries at the application layer. This > information is cached even across DHCP lease assignments from a new > subnet=2C where DNS caches are usually flushed. The result is that the > web browser cannot view the first web page that the user tries to visit. > The captive portal page is always shown instead. >=20 > Suggestion: DNS proxies MUST NOT respond with an answer if the name is > not resolvable. DNS proxies MUST NOT synthesize an answer. >=20 >=20 > Issue: responding to all DNS requests with a fake IP (commonly 1.1.1.1) >=20 > Goal: to catch *different* kinds of traffic than the previous issue > (this is no explanation=2C I've never had one explained to me in a way I > understand) >=20 > Background: Some proxies return synthetic responses with "fake" IP > addresses. While 1.1.1.1 is not currently allocated=2C it may be in the > future. Using it is a bad choice. In fact=2C this whole practice is > completely wtong. >=20 > Suggestion: Same as above. DNS proxies MUST NOT synthesize an answer. >=20 >=20 > The above suggestions might be a little strong. There are valid cases > where a proxy inside of a corporate network might need to synthesize > incorrect answers. These situations are better described as "internal > corporate policy". i.e. Notwithstanding the suggestions above=2C if you > want to break your own network=2C there are often valid reasons for doing= so. >=20 > Alan DeKok. > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors --_cbccff4c-82f2-41b1-bbaf-a0440d791d25_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are also some pretty =3B nasty effects on multi-homed hosts who m= ay send DNS queries on
multiple interfaces=2C including the "WiFi hotspo= t" interface.

This can result in a user who has a perfectly service= able alternative connection (e.g. Ethernet=2C HSDPA=2C etc.)
being unabl= e to resolve names because their WiFi hotspot has decided to (quickly) retu= rn a synthesized (bogus)
answer to every query.

The load of sup= port calls this can create is so large that the practice of forbidding mult= i-homing (via use of
suitably configured connection managers) has become= quite common place.  =3B


>=3B Date: Sat=2C 30 May 2009 0= 9:31:08 +0200
>=3B From: aland@deployingradius.com
>=3B To: secdi= r-secretary@mit.edu=3B raft-ietf-dnsext-dnsproxy.all@tools.ietf.org=3B aaa-= doctors@ietf.org
>=3B Subject: [AAA-DOCTORS] Secdir review of draft-ie= tf-dnsext-dnsproxy-05
>=3B
>=3B I have reviewed this document as= part of the security directorate's
>=3B ongoing effort to review all = IETF documents being processed by the
>=3B IESG. These comments were = written primarily for the benefit of the
>=3B security area directors.= Document editors and WG chairs should treat
>=3B these comments just= like any other last call comments.
>=3B
>=3B Over all=2C the = document appears to be clear.
>=3B
>=3B
>=3B I wonder ab= out the following text in section 4.5=2C however:
>=3B
>=3B N= B: any DNS proxy (such as those commonly found in WiFi hotspot
>=3B = "walled gardens") which transparently intercepts all DNS queries=2C and>=3B which returns unsigned responses to signed queries=2C will also = cause
>=3B TSIG authentication failures.
>=3B
>=3B
&= gt=3B The problem with WiFi hotspot DNS proxies is much=2C much=2C worse = than
>=3B this simple paragraph would suggest. There are issues found= in in those
>=3B deployments that are not discussed in this document.= I will summarize
>=3B them here:
>=3B
>=3B
>=3B Iss= ue: responding to all DNS requests with the IP of the hotspot
>=3B >=3B Goal: to guide all client traffic to the hotspot
>=3B
>= =3B Background: Many client machines have VPN software that checks for the<= br>>=3B existence of "internal" corporate DNS names. If the names resolv= e=2C the
>=3B client is assumed to be "within" the corporate network. = If the name
>=3B does not resolve=2C the client is assumed to be else= where=2C and the VPN
>=3B software behaves differently. DNS proxies t= hat return an answer for all
>=3B names result in the client erroneous= ly believing it is in the "internal"
>=3B network. Various things the= n fail in weird and wonderful ways.
>=3B
>=3B Even when VPN so= ftware doesn't exist=2C this practice can cause other
>=3B problems. = A commonly used web browser (I.E. from a major vendor) can
>=3B cache = the results of DNS queries at the application layer. This
>=3B inform= ation is cached even across DHCP lease assignments from a new
>=3B sub= net=2C where DNS caches are usually flushed. The result is that the
>= =3B web browser cannot view the first web page that the user tries to visit= .
>=3B The captive portal page is always shown instead.
>=3B
= >=3B Suggestion: DNS proxies MUST NOT respond with an answer if the name = is
>=3B not resolvable. DNS proxies MUST NOT synthesize an answer.>=3B
>=3B
>=3B Issue: responding to all DNS requests with a = fake IP (commonly 1.1.1.1)
>=3B
>=3B Goal: to catch *different* = kinds of traffic than the previous issue
>=3B (this is no explanation= =2C I've never had one explained to me in a way I
>=3B understand)
= >=3B
>=3B Background: Some proxies return synthetic responses with = "fake" IP
>=3B addresses. While 1.1.1.1 is not currently allocated=2C= it may be in the
>=3B future. Using it is a bad choice. In fact=2C = this whole practice is
>=3B completely wtong.
>=3B
>=3B Sug= gestion: Same as above. DNS proxies MUST NOT synthesize an answer.
>= =3B
>=3B
>=3B The above suggestions might be a little strong.= There are valid cases
>=3B where a proxy inside of a corporate netw= ork might need to synthesize
>=3B incorrect answers. These situations= are better described as "internal
>=3B corporate policy". i.e. Notwi= thstanding the suggestions above=2C if you
>=3B want to break your own= network=2C there are often valid reasons for doing so.
>=3B
>= =3B Alan DeKok.
>=3B _______________________________________________=
>=3B AAA-DOCTORS mailing list
>=3B AAA-DOCTORS@ietf.org
>= =3B https://www.ietf.org/mailman/listinfo/aaa-doctors
= --_cbccff4c-82f2-41b1-bbaf-a0440d791d25_-- From dromasca@avaya.com Thu Jun 4 03:53:04 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B902E28C2A4; Thu, 4 Jun 2009 03:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuQyD+e-hAJn; Thu, 4 Jun 2009 03:52:58 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 9ED293A6C16; Thu, 4 Jun 2009 03:52:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,305,1241409600"; d="scan'208";a="172901076" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Jun 2009 06:53:00 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Jun 2009 06:53:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Jun 2009 12:52:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Evaluation: draft-floyd-tcpm-ackcc-05.txt to Informational RFC Thread-Index: AcnlAdUPMdhx8wHmSXCAk/2FtfAJDwAAItvA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: Evaluation: draft-floyd-tcpm-ackcc-05.txt to Informational RFC X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 10:53:04 -0000 =20 A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-floyd-tcpm-ackcc-05.txt The process for such documents is described at http://www.rfc-editor.org/indsubs.html. Thank you, The IESG Secretary Technical Summary This document describes a possible congestion control mechanism for acknowledgement traffic (ACKs) in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts, the TCP data sender and the TCP data receiver. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community. Working Group Summary (This document is an independent submission to the RFC Editor.) Document Quality (This document is an independent submission to the RFC Editor.) Personnel Lars Eggert (lars.eggert@nokia.com) reviewed this document for the IESG. RFC Editor Note The IESG thinks that this work is related to IETF work done in WG TCPM, but this does not prevent publishing. IESG Note The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. From dromasca@avaya.com Sun Jun 7 06:04:15 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F9A3A6BEA; Sun, 7 Jun 2009 06:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQkDbHooZKko; Sun, 7 Jun 2009 06:04:14 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 77A473A6BE0; Sun, 7 Jun 2009 06:04:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,319,1241409600"; d="scan'208";a="173169130" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Jun 2009 09:04:16 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Jun 2009 09:04:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Jun 2009 15:04:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol Action: 'Carrying Location Objects in RADIUS and Diameter' to Proposed Standard Thread-Index: AcnmFRUp5Uq3IbPsR8KuYhAOimg0XABW0k8g From: "Romascanu, Dan (Dan)" To: , "radext mailing list" , Subject: [AAA-DOCTORS] FW: Protocol Action: 'Carrying Location Objects in RADIUS and Diameter' to Proposed Standard X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 13:04:15 -0000 =20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, June 05, 2009 10:37 PM To: IETF-Announce Cc: geopriv mailing list; geopriv chair; Internet Architecture Board; RFC Editor Subject: Protocol Action: 'Carrying Location Objects in RADIUS and Diameter' to Proposed Standard=20 The IESG has approved the following document: - 'Carrying Location Objects in RADIUS and Diameter ' as a Proposed Standard This document is the product of the Geographic Location/Privacy Working Group.=20 The IESG contact persons are Cullen Jennings and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-24.txt Technical Summary This document specifies RADIUS attributes for conveying access network location information, in both civic and geospatial location formats, along with access network ownership. The distribution of location information is a privacy sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed throughout, for various scenarios of location information function within AAA. WG Summary The WG reached solid consensus to advance this document after a number of iterations. The WG had initial hesitation about taking on the work, because the RFC 4119 pidf_lo object could not be used within RADIUS attribute size constraints. The WG concerns were met with an eventual functional compromise, providing a mandated attribute with the pidf_lo policy markers, and opaque attributes pointing to the geopriv location formats developed for DHCP which had constraints similar to RADIUS. =20 This document is a Critical Requirement for 3GPP. Both the GSM Association and the ITU have specified Operator Namespace Tokens for use in this protocol. (The document has customers). Document Quality The protocol was reviewed in depth by both the GEOPRIV and RADEXT Working Groups. RADEXT's formal issues list was cleared. GEOPRIV and RADEXT had some overlapping issues, especially location information design, and scenario evaluation. The conclusion that location- aware AAA systems need to be able to implement the formats and processing found in the GEOPRIV documents was very useful, because it meant that GEOPRIV did not have to intercept or anticipate any enhancements of the RADIUS data model.=20 The document is especially careful in projecting GEOPRIV's paranoia towards exposing location information. Section 8.3 contains a detailed review against the previously defined requirements related to this, and the Security Considerations details the use of security services RADIUS provides as the using protocol to meet requirements. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From dromasca@avaya.com Tue Jun 9 09:08:30 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506343A6921; Tue, 9 Jun 2009 09:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eg4tzzE0jFGU; Tue, 9 Jun 2009 09:08:28 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 8AD5F3A687A; Tue, 9 Jun 2009 09:08:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,333,1241409600"; d="scan'208";a="173392392" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Jun 2009 12:08:33 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Jun 2009 12:08:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jun 2009 18:08:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [New-work] WG Review: Recharter of Geographic Location/Privacy(geopriv) Thread-Index: AcnpG4VVbgy3PJJ5QaC+McmZUJOskgAAP1eA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: [New-work] WG Review: Recharter of Geographic Location/Privacy(geopriv) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 16:08:30 -0000 =20 -----Original Message----- From: new-work-bounces@ietf.org [mailto:new-work-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, June 09, 2009 7:00 PM To: new-work@ietf.org Subject: [New-work] WG Review: Recharter of Geographic Location/Privacy(geopriv) A modified charter has been submitted for the Geographic Location/Privacy (geopriv) working group in the Real-time Applications and Infrastructure Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only.=20 Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 16, 2009. Geographic Location/Privacy (geopriv) -------------------------------------- Last Modified: 2009-05-29 Chair(s): - Richard Barnes - Alissa Cooper Real-time Applications and Infrastructure Area Director(s): - Robert Sparks - Cullen Jennings Real-time Applications and Infrastructure Area Advisor: - Cullen Jennings Technical Advisor(s): - Lisa Dusseault Mailing Lists: General Discussion: geopriv@ietf.org To Subscribe: geopriv-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/geopriv/index.html Description of Working Group: The IETF has recognized that many applications are emerging that require geographic and civic location information about resources and entities, and that the representation and transmission of that information has significant privacy and security implications. We have created a suite of protocols that allow such applications to represent and transmit such location objects and to allow users to express policies on how these representations are exposed and used. The IETF has also begun working on creating applications that use these capabilities, for emergency services, general real-time communication, and other usages. The GEOPRIV working group is chartered to continue to develop and refine representations of location in Internet protocols, and to analyze the authorization, integrity, and privacy requirements that must be met when these representations of location are created, stored, and used. The group will create and refine mechanisms for the transmission of these representations that address the requirements that have been identified. The working group will work with other IETF working groups and other standards development organizations that are building applications that use location information to ensure that the requirements are well understood and met, and that no additional security or privacy issues related to location are left unaddressed as these location information is incorporated into other protocols. It remains a goal of the GEOPRIV working group to deliver specifications of broad applicability that will become mandatory to implement for IETF protocols that are location aware. This working group will not develop location-determining technology. However, the IETF acknowledges that information used in the location- determination process will in some cases need to be carried over the Internet. Where necessary, this working group will develop protocols or protocol extensions to encode location-determination data structures defined elsewhere. This working group will not develop technologies to directly address any particular regulatory requirements (e.g. 9-1-1). The group will continue to coordinate with any other IETF entities that are working on those problems to ensure the technologies created here meet the needs of those entities, and that the authorization, integrity, and privacy requirements on the mechanisms provided by these technologies continue to be met. Goals and Milestones: Done Discuss initial geopriv scenarios and application requirements=20 i-d's Done Discuss initial geographic location privacy and security requirements i-d. Done Initial i-d on geographic information protocol design, including privacy and security techniques. Done Review charter and initial i-ds with AD, and have IESG consider rechartering if necessary. Done Submit geopriv scenarios and application requirements to IESG for publication as Informational RFCs Done Submit security/privacy requirements I-D to IESG for publication=20 As Informational RFC. Done Submit PIDF-LO basic geopriv object draft as a PS Done Initial Common Rules base object draft Done Initial Common Rules GEOPRIV object draft Done Submit DHCP Civil draft as a PS Done Resubmit Conveying Location Objects in RADIUS and Diameter to the IESG for publication as PS Done Submit Additional Civic PIDF-LO types (updating 4119) to the IESG for publication as PS Done Submit minimal HTTP based protocol satisfying baseline requirements specified in the Layer 7 Location Conveyance Protocol=20 Problem Statement and Requirements to the IESG for publication as=20 PS Done Submit PIDF-LO Usage Clarifications and Recommendations (updating 4119) to the IESG for publication as PS Done Submit Layer 7 Location Conveyance Protocol Problem Statement and Requirements to the IESG for publication as Informational Done Submit recommendations for representing civic addresses in PIDF-LO to the IESG for publication as BCP Done Submit Recommendations for Retransmission in SIP Location Conveyance to the IESG for publication as Informational Done Submit Requirements for Location by Reference Protocols to the IESG for publication as Informational Done Submit a LIS Discovery Mechanism to the IESG for publication as a PS Jun 2009 Resubmit Geolocation Policy to the IESG for publication as PS Sep 2009 Submit an draft for DHCP geodetic location to the IESG for publication as PS to obsolete 3825 Sep 2009 Submit an Architecture for Location and Location Privacy to the IESG for publication as Informational Dec 2009 Submit a URI scheme for directly expressing geodetic location to the IESG for publication as PS Dec 2009 Submit a DHCP Option for a Location Uniform Resource Identifier (URI) to the IESG for publication as PS Dec 2009 Submit a Document Format for Filtering and Reporting PIDF-LO Location Notifications to the IESG for publication as PS _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From dromasca@avaya.com Tue Jun 9 09:19:08 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBB0A3A6A07; Tue, 9 Jun 2009 09:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1LzX6IG---j; Tue, 9 Jun 2009 09:19:07 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 7196D3A6784; Tue, 9 Jun 2009 09:19:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,333,1241409600"; d="scan'208";a="173393865" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Jun 2009 12:19:13 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 09 Jun 2009 12:19:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jun 2009 18:18:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) Thread-Index: AcnpHX3T3wUi4HwmS82JJVibxO72EwAAFIfA From: "Romascanu, Dan (Dan)" To: , Subject: [AAA-DOCTORS] FW: WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 16:19:09 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, June 09, 2009 7:15 PM To: new-work@ietf.org Subject: WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave)=20 A modified charter has been submitted for the Behavior Engineering for Hindrance Avoidance (behave) working group in the Transport Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 16, 2009. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- Last Modified: 2009-05-27 Current Status: Active Working Group Chair(s): Dan Wing Dave Thaler Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Mailing Lists: General Discussion: behave@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/behave Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group: The behavior of NATs varies from one implementation to another. As a result it is very difficult for applications to predict or discover the behavior of these devices. Predicting and/or discovering the behavior of NATs is important for designing application protocols and NAT traversal techniques that work reliably in existing networks. This situation is especially problematic for end- to-end applications where one or both end-points are behind a NAT, such as multiuser games, interactive multimedia and P2P download. The working group documents best current practices to enable NATs to function in as deterministic a fashion as possible. The NAT behavior practices will be application independent. This has already completed for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any additional protocol deemed necessary to handle. The WG has documented approaches for characterizing and testing NAT devices. BEHAVE will develop protocol-independent toolkits usable by application protocols for NAT traversal. The WG has already produced an update of the binding discovery protocol STUN. It will now produce a relay protocol that focuses on security that is usable with both IPv4 and IPv6, and capable of relaying between the two IP versions. The goal of this work is to encourage migration to IPv6. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. The BEHAVE WG will design solutions for the following six translation scenarios; other scenarios are out of scope: 1. An IPv6 network to IPv4 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv6 network of arbitary size. Port translation is necessary on the IPv4 side for efficient IPv4 address usage. 2. IPv6 Internet to an IPv4 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function services is intended to service a specific IPv4 network using either private or public IPv4 addresses. Because this scenario has different constraints compared to (1), e.g. the IPv4 hosts that are to be reachable over IPv6 can be enumerated. The WG should attempt to design a simpler solution with less impact on applications. 3. An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. 4. IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. 5. An IPv6 network to an IPv4 network, i.e., perform translation between IPv6 and IPv4 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). 6. An IPv4 network to an IPv6 network, i.e., perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The fundamental parts of ICMP are also required to work. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation. The translators should support multicast traffic and its control traffic (IGMP and MLD) across them, both Single Source Multicast (SSM) and Any Source Multicast (ASM). However, the WG may determine that it becomes too complex or too difficult to realize with maintained functionality, for some or all cases of multicast functionality. Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications. DNS is a crucial part in making a large number of applications work across a translator. Thus the solution to the above translation cases shall include recommendations for DNS. If additional DNS functionality is needed, it may be developed. Any DNS extensions must be developed together with the DNSEXT WG, including issuing a joint WG last call for any documents. The WG needs to determine the best method for providing address space to a translator in the different deployment cases and documenting the pros and cons of the suggested approaches. The WG is to seek input from the Routing, Operations and Internet areas. Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution. Goals and Milestones: Done Submit BCP that defines unicast UDP behavioral requirements=20 for NATs to IESG Done Submit a BCP that defines TCP behavioral requirements for=20 NATs to IESG Done Submit a BCP that defines ICMP behavioral requirements for=20 NATs to IESG Done Submit informational that discusses current NAT traversal=20 techniques used by applications Done Submit BCP that defines multicast UDP Done Submit revision of RFC 3489 to IESG behavioral requirements=20 for NATs to IESG Done Submit informational document for rfc3489bis test vectors Done Submit experimental document that describes how an=20 application can determine the type of NAT it is behind Done Submit BCP document for DCCP NAT behavior Jun 2009 Submit BCP document for SCTP NAT behavior Done Submit standards-track relay protocol Done Determine relative prioritization of the four translation=20 cases.=20 Sep 2009 Submit standards-track document for relaying of a TCP=20 bytestream Jun 2009 Submit standard-track document of an IPv6 relay protocol to=20 IESG Done Determine what solutions(s) and components are needed to=20 solve each of the four cases. Create new milestones for the=20 solution(s) and the components. Jul 2009 Submit standards-track TURN-URI document Sep 2009 Submit informational for framework for IPv6/IPv4 translation=20 document Sep 2009 Submit standards-track stateless IPv6/IPv4 translation=20 document Sep 2009 Submit standards-track stateful IPv6/IPv4 translation=20 document Sep 2009 Submit standards-track DNS rewriting for IPv6/IPv4=20 translation document Nov 2009 Submit standards-track FTP ALG for IPv6/IPv4 translation=20 document Nov 2009 Submit standards-track IPv6 prefix for IPv6/IPv4 translator=20 document Mar 2010 Submit BCP large scale NAT requirements document From dromasca@avaya.com Tue Jun 9 10:17:43 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED8F28C18E; Tue, 9 Jun 2009 10:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgL03b+1fkBE; Tue, 9 Jun 2009 10:17:43 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id B7C1A3A6B77; Tue, 9 Jun 2009 10:17:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,334,1241409600"; d="scan'208";a="173401119" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Jun 2009 13:17:47 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Jun 2009 13:17:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jun 2009 19:17:25 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recharter: ISMS Thread-Index: Acno15ngbywwnJ8UQ7+4FDVMH9D+vgATmAWw From: "Romascanu, Dan (Dan)" To: , , Subject: [AAA-DOCTORS] FW: Recharter: ISMS X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 17:17:44 -0000 Please send me your comments and concerns before Wednesday 6/17.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Tuesday, June 09, 2009 10:55 AM To: iesg@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 --------------------------------------------------------------------- From dromasca@avaya.com Tue Jun 9 10:34:16 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB9FC28C1AA; Tue, 9 Jun 2009 10:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TS4ffDWQztf8; Tue, 9 Jun 2009 10:34:15 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id D233628C1A3; Tue, 9 Jun 2009 10:34:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,334,1241409600"; d="scan'208";a="148078476" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 Jun 2009 13:34:18 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Jun 2009 13:34:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jun 2009 19:34:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internal WG Review: Recharter of Diameter Maintenance and Extensions (dime) Thread-Index: AcnoZyv1PjqE5ACKQ9Wlf2B94pCRJAAwUGtw From: "Romascanu, Dan (Dan)" To: , , Subject: [AAA-DOCTORS] FW: Internal WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 17:34:16 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Monday, June 08, 2009 9:30 PM To: iesg@ietf.org; iab@iab.org; Hannes.Tschofenig@gmx.net; dave@frascone.com Subject: Internal WG Review: Recharter of Diameter Maintenance and Extensions (dime)=20 A new charter for the Diameter Maintenance and Extensions working group (dime) in the Operations and Management Area of the IETF is being considered. The draft charter is provided below for your review and comment. Review time is one week. The IETF Secretariat Diameter Maintenance and Extensions (dime) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Last Modified: 2009-06-04 Current Status: Working Group Chair(s): Hannes Tschofenig David Frascone Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Secretary(ies): Victor Fajardo Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting and provisioning in network access as well as for other applications environments (e.g., IP telephony, mobility). The IETF has completed work on the Diameter Base protocol and is working on revising the base protocol specification. There is on-going work on defining RADIUS extensions and the DIME WG will ensure that work done in RADEXT is also available for Diameter. The DIME working group plains to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes, such NAI routing or capability update extensions. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Diameter QoS extensions. This work focuses on extensions to Diameter to support QoS information to be authorized and provisioned in AAA deployments. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Diameter extensions for mobility protocols, such as Mobile IPv6 and Proxy Mobile IPv6. Diameter extensions to support handover keying developed in the HOKEY WG are part of this effort. - New Diameter applications, such as the Diameter NAT control application. This group will also conduct work on new Diameter applications with a Diameter application for configuring NATs as the first item. Additionally, AAA systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed. Coordination with other IETF working groups and other SDOs will used to ensure this. Goals and Milestones: Done Submit 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Nov 2009 Submit 'Revision of Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Aug 2009 Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Done Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Jan 2010 Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Jun 2009 Submit new DIME charter to the IESG Jun 2009 Submit 'Updated IANA Considerations for Diameter Command Code Allocations' as DIME working group item Jul 2009 Submit 'Updated IANA Considerations for Diameter Command Code Allocations' to the IESG for consideration as a Proposed Standard Jul 2009 Submit 'Diameter NAT Control Application' as DIME working group item Jul 2009 Submit 'Diameter Capabilities Update' as DIME working group item Nov 2009 Submit ' Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Nov 2009 Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Nov 2009 Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Jan 2010 Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard From d.b.nelson@comcast.net Tue Jun 9 20:23:14 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8B43A6C2A for ; Tue, 9 Jun 2009 20:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIvC3XgEWqNS for ; Tue, 9 Jun 2009 20:23:13 -0700 (PDT) Received: from QMTA11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by core3.amsl.com (Postfix) with ESMTP id BFC293A6C29 for ; Tue, 9 Jun 2009 20:23:13 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA11.emeryville.ca.mail.comcast.net with comcast id 228K1c0070S2fkCAB3PLPG; Wed, 10 Jun 2009 03:23:20 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id 23PH1c00C4H2mdz8V3PJ7h; Wed, 10 Jun 2009 03:23:20 +0000 From: "Dave Nelson" To: "'David B Harrington'" , "'Romascanu, Dan \(Dan\)'" , , , References: <019a01c9e93b$3bfcdf20$0600a8c0@china.huawei.com> Date: Tue, 9 Jun 2009 23:23:18 -0400 Message-ID: <2DFEB3A3F37D43C9B5337339B9535DF0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acno15ngbywwnJ8UQ7+4FDVMH9D+vgATmAWwAAMMVZAAEWu0gA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <019a01c9e93b$3bfcdf20$0600a8c0@china.huawei.com> Cc: 'Pasi Eronen' , 'Juergen Schoenwaelder' Subject: Re: [AAA-DOCTORS] [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 03:23:14 -0000 David B Harrington writes... > "obtaining VACM authorization information via RADIUS" seems to > violate the modularity of the RFC3411 architecture. Well, perhaps it violates the *aspirations* for modularity. It's clear to me that the access control decision is encapsulated entirely in the Access Control Subsystem. There is no ASI that allows for the ACS to obtain access control guidance from any other subsystem. We encountered that problem in the work ISMS recently completed. We created a new Transport Subsystem, and a "cache" to allow the TS to communicate with the Security Subsystem without modifying the existing ASIs. It's pretty clear, in hind sight, that the Security Subsystem design was never sufficiently modular to foresee the possibility of the security mechanism being provided outside of that subsystem. Are you suggesting we use the same tactic here? That we create a new AAA Subsystem and a "cache" that allows it to communicate with the ACS? > 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. In other words, we create an AAA Subsystem. > 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. Well, such a thing is possible, of course, but in the absence of a specific mechanism, simply providing access by default raises real security concerns, whether or not it is a matter of local policy. > 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. By the same logic, as the binding mechanism *is* the responsibility of a specific ACM, who's to say it cannot chose to use RADIUS? What mandates that the source of access control information be "modular"? Nothing that I see in the current definition of the ACS. > RADIUS should supply a model-independent policy name, with no RADIUS > knowledge of how the binding will occur within an AC model. Having an AAA Subsystem might be a good thing. My question is whether it is a necessary thing, and whether it would be worth the extra time and effort. > The VACM extension should apply that RADIUS-provisioned policy name to > the authenticated identity using the VACM-specific username-to-groupname > mapping table. I think that's exactly what's been proposed. From dbharrington@comcast.net Tue Jun 9 12:48:16 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B15F28C1C7 for ; Tue, 9 Jun 2009 12:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1utjoRMEZudf for ; Tue, 9 Jun 2009 12:48:12 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 752E63A6E43 for ; Tue, 9 Jun 2009 12:48:11 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA10.westchester.pa.mail.comcast.net with comcast id 1m731c0020bG4ec5AvoJHr; Tue, 09 Jun 2009 19:48:18 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA03.westchester.pa.mail.comcast.net with comcast id 1voH1c00s0UQ6dC3PvoJ3p; Tue, 09 Jun 2009 19:48:18 +0000 From: "David B Harrington" To: "'Romascanu, Dan \(Dan\)'" , , , References: Date: Tue, 9 Jun 2009 15:48:16 -0400 Message-ID: <019a01c9e93b$3bfcdf20$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acno15ngbywwnJ8UQ7+4FDVMH9D+vgATmAWwAAMMVZA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: X-Mailman-Approved-At: Wed, 10 Jun 2009 01:18:32 -0700 Cc: 'Juergen Schoenwaelder' , 'Pasi Eronen' Subject: Re: [AAA-DOCTORS] [MIB-DOCTORS] FW: Recharter: ISMS X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 19:48:16 -0000 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@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: mib-doctors-bounces@ietf.org > [mailto:mib-doctors-bounces@ietf.org] On Behalf Of Romascanu, > Dan (Dan) > Sent: Tuesday, June 09, 2009 1:17 PM > To: ops-dir@ietf.org; aaa-doctors@ietf.org; mib-doctors@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@ietf.org [mailto:iesg-bounces@ietf.org] On > Behalf Of > Pasi.Eronen@nokia.com > Sent: Tuesday, June 09, 2009 10:55 AM > To: iesg@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@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From dbharrington@comcast.net Tue Jun 9 22:11:06 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E52503A6A46 for ; Tue, 9 Jun 2009 22:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQC2j13hHudA for ; Tue, 9 Jun 2009 22:11:05 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 33E493A68B3 for ; Tue, 9 Jun 2009 22:11:04 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA08.westchester.pa.mail.comcast.net with comcast id 24ur1c0021GhbT8585BBso; Wed, 10 Jun 2009 05:11:11 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA07.westchester.pa.mail.comcast.net with comcast id 25BA1c00M0UQ6dC3T5BBER; Wed, 10 Jun 2009 05:11:11 +0000 From: "David B Harrington" To: "'Dave Nelson'" , "'Romascanu, Dan \(Dan\)'" , , , References: <019a01c9e93b$3bfcdf20$0600a8c0@china.huawei.com> <2DFEB3A3F37D43C9B5337339B9535DF0@NEWTON603> Date: Wed, 10 Jun 2009 01:11:09 -0400 Message-ID: <01dd01c9e989$de473610$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acno15ngbywwnJ8UQ7+4FDVMH9D+vgATmAWwAAMMVZAAEWu0gAAELMrg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <2DFEB3A3F37D43C9B5337339B9535DF0@NEWTON603> X-Mailman-Approved-At: Wed, 10 Jun 2009 01:18:32 -0700 Cc: 'Pasi Eronen' , 'Juergen Schoenwaelder' Subject: Re: [AAA-DOCTORS] [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 05:11:07 -0000 Hi, Randy Presuhn described it best. The simplest way to approach this problem is to have the RADIUS authorization attributes simply there in the background. Screw the ASIs; we want to finish this within five years. A RADIUS-aware ACM can simply utilize the RADIUS attributes. 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. When the charter says that RADIUS provides VACM username-to-groupname dynamic provisioning, that is wrong. RADIUS provides a policy name. How that translates to VACM access control is dependent on the (extended) VACM access control model. That permits additional access control models to also utilize the RADIUS attributes. dbh > -----Original Message----- > From: Dave Nelson [mailto:d.b.nelson@comcast.net] > Sent: Tuesday, June 09, 2009 11:23 PM > To: 'David B Harrington'; 'Romascanu, Dan (Dan)'; > ops-dir@ietf.org; aaa-doctors@ietf.org; mib-doctors@ietf.org > Cc: 'Juergen Schoenwaelder'; 'Pasi Eronen' > Subject: RE: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS > > David B Harrington writes... > > > "obtaining VACM authorization information via RADIUS" seems to > > violate the modularity of the RFC3411 architecture. > > Well, perhaps it violates the *aspirations* for modularity. > It's clear to > me that the access control decision is encapsulated entirely > in the Access > Control Subsystem. There is no ASI that allows for the ACS > to obtain access > control guidance from any other subsystem. We encountered > that problem in > the work ISMS recently completed. We created a new Transport > Subsystem, and > a "cache" to allow the TS to communicate with the Security > Subsystem without > modifying the existing ASIs. It's pretty clear, in hind > sight, that the > Security Subsystem design was never sufficiently modular to > foresee the > possibility of the security mechanism being provided outside of that > subsystem. Are you suggesting we use the same tactic here? > That we create > a new AAA Subsystem and a "cache" that allows it to > communicate with the > ACS? > > > 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. > > In other words, we create an AAA Subsystem. > > > 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. > > Well, such a thing is possible, of course, but in the absence > of a specific > mechanism, simply providing access by default raises real > security concerns, > whether or not it is a matter of local policy. > > > 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. > > By the same logic, as the binding mechanism *is* the > responsibility of a > specific ACM, who's to say it cannot chose to use RADIUS? > What mandates > that the source of access control information be "modular"? > Nothing that I > see in the current definition of the ACS. > > > RADIUS should supply a model-independent policy name, with no RADIUS > > knowledge of how the binding will occur within an AC model. > > Having an AAA Subsystem might be a good thing. My question > is whether it is > a necessary thing, and whether it would be worth the extra > time and effort. > > > The VACM extension should apply that RADIUS-provisioned > policy name to > > the authenticated identity using the VACM-specific > username-to-groupname > > mapping table. > > I think that's exactly what's been proposed. > > > From j.schoenwaelder@jacobs-university.de Tue Jun 9 23:43:40 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12B6B3A69A6; Tue, 9 Jun 2009 23:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne63DS-3K28i; Tue, 9 Jun 2009 23:43:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D644C3A67F5; Tue, 9 Jun 2009 23:43:38 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3E95C0011; Wed, 10 Jun 2009 08:43:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id N1-Aa+a94XdJ; Wed, 10 Jun 2009 08:43:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89860C0006; Wed, 10 Jun 2009 08:43:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0744EB35F4F; Wed, 10 Jun 2009 08:43:41 +0200 (CEST) Date: Wed, 10 Jun 2009 08:43:41 +0200 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20090610064341.GA5220@elstar.local> Mail-Followup-To: Dave Nelson , 'David B Harrington' , "'Romascanu, Dan (Dan)'" , "ops-dir@ietf.org" , "aaa-doctors@ietf.org" , "mib-doctors@ietf.org" , 'Pasi Eronen' References: <019a01c9e93b$3bfcdf20$0600a8c0@china.huawei.com> <2DFEB3A3F37D43C9B5337339B9535DF0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2DFEB3A3F37D43C9B5337339B9535DF0@NEWTON603> User-Agent: Mutt/1.5.19 (2009-01-05) X-Mailman-Approved-At: Wed, 10 Jun 2009 01:18:32 -0700 Cc: 'David B Harrington' , "ops-dir@ietf.org" , "aaa-doctors@ietf.org" , "mib-doctors@ietf.org" , 'Pasi Eronen' Subject: Re: [AAA-DOCTORS] [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 06:43:40 -0000 On Wed, Jun 10, 2009 at 05:23:18AM +0200, Dave Nelson wrote: > Having an AAA Subsystem might be a good thing. My question is whether it is > a necessary thing, and whether it would be worth the extra time and effort. RFC 3411 defines the Access Control Subsystem, see sections 3.1.2 and 4.3. David is perhaps right that the wording of the charter text is not 100% RFC 3411 conform but since I believe it is good enough in documenting what the WG wants to achieve. I personally would have loved to have an initial ID for the RADIUS ACM integration work available to support the recharerting discussion; this is where the wording really matters. But it seems we won't get such an initial document... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed Jun 10 01:24:42 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5E43A6DA5; Wed, 10 Jun 2009 01:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5po9KsJWRg2A; Wed, 10 Jun 2009 01:24:42 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 074023A6DEE; Wed, 10 Jun 2009 01:24:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,339,1241409600"; d="scan'208";a="163851567" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 10 Jun 2009 04:24:31 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 10 Jun 2009 04:24:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jun 2009 10:24:10 +0200 Message-ID: In-Reply-To: <20090610064341.GA5220@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS Thread-Index: Acnpls8mewrc6/T9R5agzz65IJidHgADeDfA References: <019a01c9e93b$3bfcdf20$0600a8c0@china.huawei.com> <2DFEB3A3F37D43C9B5337339B9535DF0@NEWTON603> <20090610064341.GA5220@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Dave Nelson" Cc: aaa-doctors@ietf.org, David B Harrington , ops-dir@ietf.org, Pasi Eronen , mib-doctors@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 08:24:43 -0000 Unless there are special reasons to keep some of the interactions confidential I suggest to move the discussion to the isms mail list.=20 Dan =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Wednesday, June 10, 2009 9:44 AM > To: Dave Nelson > Cc: 'David B Harrington'; Romascanu, Dan (Dan);=20 > ops-dir@ietf.org; aaa-doctors@ietf.org; mib-doctors@ietf.org;=20 > 'Pasi Eronen' > Subject: Re: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS >=20 > On Wed, Jun 10, 2009 at 05:23:18AM +0200, Dave Nelson wrote: > =20 > > Having an AAA Subsystem might be a good thing. My question=20 > is whether=20 > > it is a necessary thing, and whether it would be worth the=20 > extra time and effort. >=20 > RFC 3411 defines the Access Control Subsystem, see sections=20 > 3.1.2 and 4.3. David is perhaps right that the wording of the=20 > charter text is not 100% RFC 3411 conform but since I believe=20 > it is good enough in documenting what the WG wants to achieve. >=20 > I personally would have loved to have an initial ID for the=20 > RADIUS ACM integration work available to support the=20 > recharerting discussion; this is where the wording really=20 > matters. But it seems we won't get such an initial document... >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From dbharrington@comcast.net Wed Jun 10 02:51:50 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11FC728C0FB for ; Wed, 10 Jun 2009 02:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5mSXc5AXXh6 for ; Wed, 10 Jun 2009 02:51:49 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 1712F28C0E4 for ; Wed, 10 Jun 2009 02:51:49 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA02.westchester.pa.mail.comcast.net with comcast id 29rW1c0060bG4ec529rwJa; Wed, 10 Jun 2009 09:51:56 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA03.westchester.pa.mail.comcast.net with comcast id 29rv1c00N0UQ6dC3P9rwYg; Wed, 10 Jun 2009 09:51:56 +0000 From: "David B Harrington" To: "'Romascanu, Dan \(Dan\)'" , "'Juergen Schoenwaelder'" , "'Dave Nelson'" References: <019a01c9e93b$3bfcdf20$0600a8c0@china.huawei.com> <2DFEB3A3F37D43C9B5337339B9535DF0@NEWTON603> <20090610064341.GA5220@elstar.local> Date: Wed, 10 Jun 2009 05:51:54 -0400 Message-ID: <01fc01c9e9b1$16981a80$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acnpls8mewrc6/T9R5agzz65IJidHgADeDfAAAMWHGA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Cc: aaa-doctors@ietf.org, mib-doctors@ietf.org, ops-dir@ietf.org, 'Pasi Eronen' Subject: Re: [AAA-DOCTORS] [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 09:51:50 -0000 Agreed. I realized after the fact that ISMS was not being CC'd. dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Wednesday, June 10, 2009 4:24 AM > To: Juergen Schoenwaelder; Dave Nelson > Cc: David B Harrington; ops-dir@ietf.org; > aaa-doctors@ietf.org; mib-doctors@ietf.org; Pasi Eronen > Subject: RE: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS > > Unless there are special reasons to keep some of the interactions > confidential I suggest to move the discussion to the isms mail list. > > Dan > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, June 10, 2009 9:44 AM > > To: Dave Nelson > > Cc: 'David B Harrington'; Romascanu, Dan (Dan); > > ops-dir@ietf.org; aaa-doctors@ietf.org; mib-doctors@ietf.org; > > 'Pasi Eronen' > > Subject: Re: [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS > > > > On Wed, Jun 10, 2009 at 05:23:18AM +0200, Dave Nelson wrote: > > > > > Having an AAA Subsystem might be a good thing. My question > > is whether > > > it is a necessary thing, and whether it would be worth the > > extra time and effort. > > > > RFC 3411 defines the Access Control Subsystem, see sections > > 3.1.2 and 4.3. David is perhaps right that the wording of the > > charter text is not 100% RFC 3411 conform but since I believe > > it is good enough in documenting what the WG wants to achieve. > > > > I personally would have loved to have an initial ID for the > > RADIUS ACM integration work available to support the > > recharerting discussion; this is where the wording really > > matters. But it seems we won't get such an initial document... > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > From ietfdbh@comcast.net Wed Jun 10 04:00:01 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA0828C13E for ; Wed, 10 Jun 2009 04:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNfMxLSKLZSk for ; Wed, 10 Jun 2009 04:00:00 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 7599A3A6E34 for ; Wed, 10 Jun 2009 04:00:00 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA08.westchester.pa.mail.comcast.net with comcast id 29pt1c0030cZkys58B07xD; Wed, 10 Jun 2009 11:00:07 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA10.westchester.pa.mail.comcast.net with comcast id 2B061c01K0UQ6dC3WB06Go; Wed, 10 Jun 2009 11:00:07 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Dave Nelson'" References: <019a01c9e93b$3bfcdf20$0600a8c0@china.huawei.com><2DFEB3A3F37D43C9B5337339B9535DF0@NEWTON603> <20090610064341.GA5220@elstar.local> Date: Wed, 10 Jun 2009 07:00:05 -0400 Message-ID: <020a01c9e9ba$9cf23e40$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acnpls/zHGHxJhxvTwC9PngMcAzJfwAGd16w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20090610064341.GA5220@elstar.local> Cc: aaa-doctors@ietf.org, 'David B Harrington' , ops-dir@ietf.org, 'Pasi Eronen' , mib-doctors@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 11:00:01 -0000 Hi, > RFC 3411 defines the Access Control Subsystem, see sections 3.1.2 and > 4.3. David is perhaps right that the wording of the charter text is > not 100% RFC 3411 conform but since I believe it is good enough in > documenting what the WG wants to achieve. The main reason I object to the wording is that Dave Nelson and Kaushik, the planned editors for the draft, do not seem to understand how to craft this solution without violating the modularity. I would like the charter wording to give them some guidance on this issue. > > I personally would have loved to have an initial ID for the RADIUS ACM > integration work available to support the recharerting discussion; > this is where the wording really matters. But it seems we won't get > such an initial document... agreed. A draft would have been helpful. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > OPS-DIR mailing list > OPS-DIR@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir > From d.b.nelson@comcast.net Wed Jun 10 05:03:47 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2483A6ACA for ; Wed, 10 Jun 2009 05:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wqy3uaius5DB for ; Wed, 10 Jun 2009 05:03:46 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 0D59D3A6AF4 for ; Wed, 10 Jun 2009 05:03:46 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id 2BnK1c0021HpZEsA2C3tSq; Wed, 10 Jun 2009 12:03:53 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id 2C3o1c0044H2mdz8aC3pdl; Wed, 10 Jun 2009 12:03:52 +0000 From: "Dave Nelson" To: "'David B Harrington'" , "'Romascanu, Dan \(Dan\)'" , , , References: <019a01c9e93b$3bfcdf20$0600a8c0@china.huawei.com> <2DFEB3A3F37D43C9B5337339B9535DF0@NEWTON603> <01dd01c9e989$de473610$0600a8c0@china.huawei.com> Date: Wed, 10 Jun 2009 08:03:50 -0400 Message-ID: <4F478F94E9C24469AF59E4734E9F7E89@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acno15ngbywwnJ8UQ7+4FDVMH9D+vgATmAWwAAMMVZAAEWu0gAAELMrgAA4CjOA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <01dd01c9e989$de473610$0600a8c0@china.huawei.com> Cc: 'Pasi Eronen' , 'Juergen Schoenwaelder' Subject: Re: [AAA-DOCTORS] [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 12:03:47 -0000 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. From d.b.nelson@comcast.net Wed Jun 10 05:09:20 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394733A6E52 for ; Wed, 10 Jun 2009 05:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyeKGfl+pWDE for ; Wed, 10 Jun 2009 05:09:19 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 75B3B3A6ACE for ; Wed, 10 Jun 2009 05:09:19 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id 2BhF1c0021GXsucA4C9Sky; Wed, 10 Jun 2009 12:09:26 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id 2C9P1c00P4H2mdz8TC9QW3; Wed, 10 Jun 2009 12:09:26 +0000 From: "Dave Nelson" To: "'David Harrington'" References: <019a01c9e93b$3bfcdf20$0600a8c0@china.huawei.com><2DFEB3A3F37D43C9B5337339B9535DF0@NEWTON603> <20090610064341.GA5220@elstar.local> <020a01c9e9ba$9cf23e40$0600a8c0@china.huawei.com> Date: Wed, 10 Jun 2009 08:09:25 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acnpls/zHGHxJhxvTwC9PngMcAzJfwAGd16wAATd8mA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <020a01c9e9ba$9cf23e40$0600a8c0@china.huawei.com> Cc: 'David B Harrington' , ops-dir@ietf.org, aaa-doctors@ietf.org, 'Pasi Eronen' , 'Juergen Schoenwaelder' , mib-doctors@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 12:09:20 -0000 > agreed. A draft would have been helpful. Yeah, well, it's always easier to write the requirements after you have the solution in hand. :-) From dbharrington@comcast.net Wed Jun 10 05:43:06 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0011F28C189 for ; Wed, 10 Jun 2009 05:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEH1tbtVyqli for ; Wed, 10 Jun 2009 05:43:05 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 0980A28C168 for ; Wed, 10 Jun 2009 05:43:04 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA06.westchester.pa.mail.comcast.net with comcast id 2ABj1c0061HzFnQ56CjCiE; Wed, 10 Jun 2009 12:43:12 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA14.westchester.pa.mail.comcast.net with comcast id 2CjB1c00q0UQ6dC3aCjBQM; Wed, 10 Jun 2009 12:43:12 +0000 From: "David B Harrington" To: "'Dave Nelson'" , "'Romascanu, Dan \(Dan\)'" , , , References: <019a01c9e93b$3bfcdf20$0600a8c0@china.huawei.com> <2DFEB3A3F37D43C9B5337339B9535DF0@NEWTON603> <01dd01c9e989$de473610$0600a8c0@china.huawei.com> <4F478F94E9C24469AF59E4734E9F7E89@NEWTON603> Date: Wed, 10 Jun 2009 08:43:10 -0400 Message-ID: <026701c9e9c9$03953c20$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acno15ngbywwnJ8UQ7+4FDVMH9D+vgATmAWwAAMMVZAAEWu0gAAELMrgAA4CjOAAAS65wA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4F478F94E9C24469AF59E4734E9F7E89@NEWTON603> Cc: 'Pasi Eronen' , 'Juergen Schoenwaelder' Subject: Re: [AAA-DOCTORS] [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 12:43:06 -0000 Hi, I separated my responses, since one is about charter text and the rest is an architecture and design discussion. > 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. Yes. My point is that the charter does not say this. The text is wrong. The charter says 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. What it should say is what you said: a RADIUS-provisioned policy name bound to a username, which the VACM extension will use to dynamically populate the securityToGroupname table. This may seem pedantic to you, but it is more than that to me. It took the SNMPv2/SNMPv3 community ten years, including some very acrimonious times, to get an architecture we could agree to, that was flexible enough to meet the demands of multiple segments of the community. If we want to change the architecture, then we should do so deliberately, not as a side-effect of sloppy design. I strongly object to a WG goal based on the current wording, because it is counter to the intentions of the SNMPv3 WG, and is not compatible with the RFC3411 architecture. I strongly support a WG goal based on the corrected wording. dbh From d.b.nelson@comcast.net Wed Jun 10 06:03:13 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F4428C105 for ; Wed, 10 Jun 2009 06:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYoMY5LDJJIY for ; Wed, 10 Jun 2009 06:03:12 -0700 (PDT) Received: from QMTA12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by core3.amsl.com (Postfix) with ESMTP id 4D2A63A6E81 for ; Wed, 10 Jun 2009 06:03:12 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA12.emeryville.ca.mail.comcast.net with comcast id 2B6m1c0050S2fkCACD3KPi; Wed, 10 Jun 2009 13:03:19 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id 2D351c0034H2mdz8VD36UW; Wed, 10 Jun 2009 13:03:19 +0000 From: "Dave Nelson" To: "'David B Harrington'" References: <019a01c9e93b$3bfcdf20$0600a8c0@china.huawei.com> <2DFEB3A3F37D43C9B5337339B9535DF0@NEWTON603> <01dd01c9e989$de473610$0600a8c0@china.huawei.com> <4F478F94E9C24469AF59E4734E9F7E89@NEWTON603> <026701c9e9c9$03953c20$0600a8c0@china.huawei.com> Date: Wed, 10 Jun 2009 09:03:06 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acno15ngbywwnJ8UQ7+4FDVMH9D+vgATmAWwAAMMVZAAEWu0gAAELMrgAA4CjOAAAS65wAABefJQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <026701c9e9c9$03953c20$0600a8c0@china.huawei.com> Cc: ops-dir@ietf.org, isms@ietf.org, aaa-doctors@ietf.org, 'Juergen Schoenwaelder' , 'Pasi Eronen' , mib-doctors@ietf.org Subject: Re: [AAA-DOCTORS] [OPS-DIR] [MIB-DOCTORS] FW: Recharter: ISMS X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 13:03:13 -0000 > Yes. My point is that the charter does not say this. The text is > wrong. > The charter says > 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. > What it should say is what you said: > a RADIUS-provisioned policy name bound to a username, which > the VACM extension will use to dynamically populate the > securityToGroupname table. Ah, those two sections of text read basically the same to me, not having the context of the "SNMPv3 Wars". :-) I heartily endorse that change in charter text. From dromasca@avaya.com Fri Jun 12 06:01:18 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096A63A6DFD; Fri, 12 Jun 2009 06:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBeFsuQHb-L4; Fri, 12 Jun 2009 06:01:16 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id C687E3A65A5; Fri, 12 Jun 2009 06:01:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,209,1243828800"; d="scan'208";a="148396231" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Jun 2009 09:01:22 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 12 Jun 2009 09:01:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 15:01:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for June 18, 2009 Telechat Thread-Index: AcnrWhkye5L9ggO/S8eBCXjOCmJwQgAAxjdg From: "Romascanu, Dan (Dan)" To: , , , Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for June 18, 2009 Telechat X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 13:01:18 -0000 Please find below the preliminary agenda of the IESG telechat on 6/18. Please send my your comments and questions related to the documents brought for approval and for the proposed WG charters before 6/17 COB.=20 Thanks and Regards, Dan 2.1 WG Submissions 2.1.1 New Item o draft-ietf-rmt-pi-norm-revised-13.txt NACK-Oriented Reliable Multicast Transport Protocol (Proposed Standard) - 1=20 of 4=20 Note: Document Shepherd: Lorenzo Vicisano =20 Token: Magnus Westerlund o draft-ietf-ltru-4646bis-23.txt Tags for Identifying Languages (BCP) - 2 of 4=20 Note: Martin Drst is the document shepherd..=20 Token: Alexey Melnikov o draft-ietf-ltans-dssc-08.txt Data Structure for the Security Suitability of Cryptographic Algorithms=20 (DSSC) (Proposed Standard) - 3 of 4=20 Token: Tim Polk o draft-ietf-ippm-more-twamp-02.txt More Features for the Two-Way Active Measurement Protocol - TWAMP (Proposed=20 Standard) - 4 of 4=20 Token: Lars Eggert 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item NONE 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-sipping-cc-framework-11.txt A Call Control and Multi-party usage framework for the Session Initiation=20 Protocol (SIP) (Informational) - 1 of 5=20 Token: Cullen Jennings o draft-ietf-ntp-autokey-05.txt Network Time Protocol Version 4 Autokey Specification (Informational) - 2=20 of 5=20 Token: Ralph Droms o draft-ietf-pce-p2mp-app-01.txt Applicability of the Path Computation Element (PCE) to Point-to-Multipoint=20 (P2MP) Multiprotocol Label Switching (MPLS)and Generalized MPLS (GMPLS)=20 Traffic Engineering (TE) (Informational) - 3 of 5=20 Token: Ross Callon o draft-ietf-ltru-4645bis-10.txt Update to the Language Subtag Registry (Informational) - 4 of 5=20 Note: Please read 4646bis before reviewing this document.. Martin Drst is=20 the document shepherd. This document, as a draft, includes 'bis' in its=20 name because it is a second version of RFC 4645. However, it is not a direct update of RFC 4645. RFC 4645 served to initialize the Language =20 Subtag Registry (http://www.iana.org/assignments/language-subtag-registry).=20 This document re-initializes the Language Subtag Registry based on the =20 initial state of the registry from RFC 4645, the updates to the registry=20 made in the meantime, and the additions and changes made by the work on=20 4646bis (which is a true update of RFC 4646)..=20 Token: Alexey Melnikov o draft-ietf-opsec-blackhole-urpf-04.txt Remote Triggered Black Hole filtering with uRPF (Informational) - 5 of 5=20 Token: Ron Bonica 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-sinnreich-sip-tools-06.txt Simple SIP Usage Scenario for Applications in the Endpoints (Informational)=20 - 1 of 3=20 Note: Mary is Proto Shepherd.=20 Token: Cullen Jennings o draft-eronen-enterprise-number-documentation-01.txt Enterprise Number for Documentation Use (Informational) - 2 of 3=20 Token: Dan Romascanu o draft-housley-aes-key-wrap-with-pad-02.txt Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm=20 (Informational) - 3 of 3=20 Token: Tim Polk 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item o draft-irtf-mobopts-location-privacy-solutions-13.txt Mobile IPv6 Location Privacy Solutions (Experimental) - 1 of 1=20 Note: The document shepherd is Basavaraj Patil=20 =20 Token: Jari Arkko 3.3.2 Returning Item o draft-ford-behave-top-06.txt Unintended Consequence of two NAT deployments with Overlapping Address =20 Space (Informational) - 1 of 2=20 Token: Magnus Westerlund o draft-floyd-tcpm-ackcc-05.txt Adding Acknowledgement Congestion Control to TCP (Informational) - 2 of 2=20 Token: Lars Eggert 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o Diameter Maintenance and Extensions (dime) - 1 of 2 Token: Dan Romascanu o Integrated Security Model for SNMP (isms) - 2 of 2 Token: Pasi Eronen 4.2.2 Proposed for Approval o Behavior Engineering for Hindrance Avoidance (behave) - 1 of 2 Token: Magnus Westerlund o Geographic Location/Privacy (geopriv) - 2 of 2 Token: Cullen Jennings From dromasca@avaya.com Wed Jun 24 01:36:47 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 013393A6F00; Wed, 24 Jun 2009 01:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8iOKu99RrHZ; Wed, 24 Jun 2009 01:36:46 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 958183A6A87; Wed, 24 Jun 2009 01:36:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,281,1243828800"; d="scan'208";a="165227571" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 24 Jun 2009 04:37:01 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jun 2009 04:37:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 10:36:43 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Diameter Maintenance and Extensions (dime) thread-index: Acn0QZAzKLyt0PQESK+jepaxbrJJhAAZVEBg From: "Romascanu, Dan (Dan)" To: , "Ops Directorate" Subject: [AAA-DOCTORS] FW: WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 08:36:47 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, June 23, 2009 11:30 PM To: new-work@ietf.org Subject: WG Review: Recharter of Diameter Maintenance and Extensions (dime)=20 A modified charter has been submitted for the Diameter Maintenance and Extensions (dime) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 30, 2009. Diameter Maintenance and Extensions (dime) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Last Modified: 2009-06-10 Current Status: Working Group Chair(s): Hannes Tschofenig Victor Fajardo=20 Operations and Management Area Director(s): Dan Romascanu Ronald Bonica=20 Operations and Management Area Advisor: Dan Romascanu=20 Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting and provisioning in network access as well as for other applications environments (e.g., IP telephony, mobility). The IETF has completed work on the Diameter Base protocol and is working on revising the base protocol specification. There is on-going work on defining RADIUS extensions and the DIME WG will ensure that work done in RADEXT is also available for Diameter. The DIME working group plains to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes, such NAI routing or capability update extensions. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Diameter QoS extensions. This work focuses on extensions to Diameter to support QoS information to be authorized and provisioned in AAA deployments. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Diameter extensions for mobility protocols, such as Mobile IPv6 and Proxy Mobile IPv6. Diameter extensions to support handover keying developed in the HOKEY WG are part of this effort. - New Diameter applications, such as the Diameter NAT control application. This group will also conduct work on new Diameter applications with a Diameter application for configuring NATs as the first item. Additionally, AAA systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed. Coordination with other IETF working groups and other SDOs will used to ensure this. Goals and Milestones: Done Submit 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Nov 2009 Submit 'Revision of Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Aug 2009 Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Done Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Jan 2010 Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Jun 2009 Submit new DIME charter to the IESG Jun 2009 Submit 'Updated IANA Considerations for Diameter Command Code Allocations' as DIME working group item Jul 2009 Submit 'Updated IANA Considerations for Diameter Command Code Allocations' to the IESG for consideration as a Proposed Standard Jul 2009 Submit 'Diameter NAT Control Application' as DIME working group item Jul 2009 Submit 'Diameter Capabilities Update' as DIME working group item Nov 2009 Submit ' Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Nov 2009 Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Nov 2009 Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Jan 2010 Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard From dromasca@avaya.com Wed Jun 24 01:36:51 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53C3B3A6F30; Wed, 24 Jun 2009 01:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME7fYJJK1oHW; Wed, 24 Jun 2009 01:36:50 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 14EBE28C420; Wed, 24 Jun 2009 01:36:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,281,1243828800"; d="scan'208";a="165227582" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 24 Jun 2009 04:37:06 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jun 2009 04:37:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 10:37:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Site Multihoming by IPv6 Intermediation (shim6) thread-index: Acn0QYfWiOwp43QRSaCNN9sbkS73KQAZWMPw From: "Romascanu, Dan (Dan)" To: , "Ops Directorate" , Subject: [AAA-DOCTORS] FW: WG Review: Recharter of Site Multihoming by IPv6 Intermediation (shim6) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 08:36:51 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, June 23, 2009 11:30 PM To: new-work@ietf.org Subject: WG Review: Recharter of Site Multihoming by IPv6 Intermediation (shim6)=20 A modified charter has been submitted for the Site Multihoming by IPv6 Intermediation (shim6) working group in the Internet Area of the IETF.=20 The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 30, 2009. Site Multihoming by IPv6 Intermediation (shim6) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Last Modified: 2009-06-17 Current Status: Active Working Group=20 Additional information is available at tools.ietf.org/wg/shim6 Chair(s): Kurt Lindqvist Geoff Huston=20 Internet Area Director(s): Ralph Droms Jari Arkko=20 Internet Area Advisor: Jari Arkko=20 Technical Advisor(s): Thomas Narten=20 Mailing Lists: General Discussion: shim6@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/shim6 Archive: http://www.ietf.org/mail-archive/web/shim6/current/maillist.html Description of Working Group: Earlier efforts in this working group completed the Shim6 protocol specification, documented in RFCs 5533 through 5535. This protocol is a layer 3 shim for providing locator agility with failover capabilities for IPv6 nodes. Hosts that employ Shim6 use multiple IPv6 address prefixes and setup state with peer hosts. This state can later be used to failover to a different set of locators, should the original locators stop working. The Shim6 approach has a number of advantages, such as enabling small sites to be multihomed without requiring a provider independent IPv6 address prefix for the site. But the approach has also been criticized, e.g., for the operational impacts that the use of multiple prefixes causes. At this time there is no clear view on how well Shim6 works in practice. Implementation and deployment in select networks is needed to determine its true characteristics. The Shim6 working group is chartered to track the implementation and testing or deployment efforts. The group is also expected to shepherd to completion a few remaining informational documents that complement the existing protocol specifications. The specific work items of the group are: o Write an implementation and/or deployment experience report. o Specify socket API extensions. This API enables interactions between applications and the Shim6 layer for advanced locator management, and access to information about failure detection and path exploration. It also enables some applications to turn Shim6 off. o Complete the work on the applicability draft. This draft explains in detail in which types of networks Shim6 is applicable, and what its advantages and disadvantages are. The draft will also explain how firewalls are impacted by the use of Shim6. Finally, the draft will also explain how Shim6 can be used in situations where native IPv6 connectivity is not available, such as using Shim6 over 6to4. The group will also work in co-operation with the 6MAN working group as they continue their efforts in improving IPv6 address selection mechanisms. The group shall not work on extensions to the Shim6 protocol itself at this time. However, new work items can be added through rechartering as others get completed. Goals and Milestones: Sep 2009 Next revision of the API document Nov 2009 First WG draft on an implementation report Jan 2010 Submit API document to IESG for publication as Informational RFC Jan 2010 Next revision of the applicability document Dec 2010 Submit implementation report to IESG for publication as Informational RFC Dec 2010 Submit applicability document to IESG for publication as Informational RFC Dec 2010 Close or re-charter From dromasca@avaya.com Wed Jun 24 01:49:36 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37EAC3A6963; Wed, 24 Jun 2009 01:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyzjPnbLK942; Wed, 24 Jun 2009 01:49:35 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id BCDF13A682D; Wed, 24 Jun 2009 01:49:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,282,1243828800"; d="scan'208";a="165228639" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 24 Jun 2009 04:49:50 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 24 Jun 2009 04:49:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 10:49:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: STORage Maintenance (storm) thread-index: Acn0PVLxg4O1hYVdRfa+pHaS+KtelwAa11NA From: "Romascanu, Dan (Dan)" To: "Ops Directorate" , , Subject: [AAA-DOCTORS] FW: WG Review: STORage Maintenance (storm) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 08:49:36 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Tuesday, June 23, 2009 11:00 PM To: ietf-announce@ietf.org Cc: storm@ietf.org Subject: WG Review: STORage Maintenance (storm)=20 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 30, 2009. STORage Maintenance (storm) ---------------------------------- Last Modified: 2009-06-18 Current Status: Proposed Working Group Chairs: - TBD=20 Transport Area Director(s): - Magnus Westerlund - Lars Eggert Transport Area Advisor: - Lars Eggert Mailing Lists: General Discussion: storm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/storm Archive: http://www.ietf.org/mail-archive/web/storm/index.html Description of Working Group: The IETF ips (IP Storage) and rddp (Remote Direct Data Placement) working groups have produced a significant number of storage protocols (e.g., iSCSI, iSER and FCIP) for which there is significant usage. The time has come to reflect feedback from implementation and usage into updated RFCs; this work may include: - Implementation-driven revisions and updates to existing protocols (i.e., updated RFCs that match the "running code"). - Interoperability reports as needed for the resulting revised protocols that are appropriate for Draft Standard RFC status. - Minor protocol changes or additions. Backwards compatibility is required. Significant changes to the existing protocol standards are out of scope, including any work on version 2 of any of these protocols. Security for these protocols is based on the functionality specified in RFC 3723 (Securing Block Storage Protocols over IP); the working group does not intend to make major changes or updates to that RFC. Stability is critical to the usage of these protocols, making backwards compatibility with existing implementations a requirement for all protocol changes and additions. This is a requirement for implementation compatibility - if all implementations of a protocol have done something different than what the RFC specified, then it is appropriate for a new RFC to document what the "running code" actually does and deprecate the unimplemented original behavior. Initial list of work items: (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node architecture key) and 5048 (corrections/clarifications) into one draft (3720bis), removing features that are not implemented in practice. This draft should be prepared so that it could become a Draft Standard RFC, but it is up to the WG to decide whether to advance it to Draft Standard. (2) iSCSI: Add features to support at least SAM-4 (4th version of the SCSI architecture) in a backwards-compatible fashion, as iSCSI is currently based on SAM-2. This will be a separate draft from the iSCSI update in the previous item. The Working group may add additional minor useful iSCSI features to this draft, including features from draft versions of SAM-5. The iSCSI MIB (RFC 4544) should be updated to provide SNMP support for new features as appropriate. (3) FCIP: IP Protocol number 133 was allocated to a precursor of the FCIP protocol in 2000, but that allocated number is not used by FCIP. The working group will consider whether that allocated number should be returned to IANA for future reallocation. (4) iFCP: The Address Translation mode of iFCP needs to be deprecated (SHOULD NOT implement or use), as there are significant technical problems with it as specified in RFC 4172, and moreover, only the Address Transparent mode of iFCP is in use. This change is to be done via a short draft that updates RFC 4172, as opposed to a complete rewrite of RFC 4172. A combined draft is expected that encompasses items (3) and (4); this draft should also update the iFCP MIB (RFC 4369) to deprecate support for iFCP Address Translation mode. (5) RDDP Connection Setup: Good support for MPI applications requires a small update to MPA startup functionality to allow either end of the connection to initiate. In addition, a couple of minor changes to RDDP connection setup are needed based on implementation experience. (6) iSER: Experience with Infiniband implementations suggests a few minor updates to reflect what has been done in practice. The working group is expected to maintain good working relationships with INCITS Technical Committee T10 (SCSI standards) and INCITS Technical Committee T11 (Fibre Channel standards) via overlaps in membership as opposed to appointment of formal liaisons. The liaison process (including IAB appointment of a liaison or liaisons) remains available for use if needed. Recent changes in INCITS rules have removed public access to some T10 and T11 standards documents that are expected to be needed for the WG's program of work. Arrangements have been made with T10 and T11 for IETF participants to obtain copies of specific standards their personal use in IETF work as needed; contact the WG chair(s) for details. Goals and Milestones: July 2009 First version of FCIP protocol number and iFCP Address Translation mode draft. Aug 2009 First version of iSCSI SAM-4 (and other) new features draft. Aug 2009 First version of RDDP MPA startup change draft Sep 2009 Working Group Last Call on FCIP protocol number and iFCP address change draft Sep 2009 First version of combined iSCSI draft (3720bis) Oct 2009 First version of iSER update draft Oct 2009 Working Group Last Call on RDDP MPA startup change draft. Dec 2009 Functionally complete iSCSI SAM-4 (and other) new features draft, plus iSCSI MIB update draft. Feb 2010 Working Group Last Call on iSER update draft Mar 2010 Working Group Last Call on iSCSI SAM-4 (and other) new features draft. Apr 2010 Working Group decision on whether to seek Draft Standard RFC status for the combined iSCSI draft (3720bis). [Note: decision may be made significantly before this date.] Sep 2010 Working Group Last Call on combined iSCSI draft (3720bis) and iSCSI MIB update draft. From dromasca@avaya.com Thu Jun 25 23:05:33 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1B63A6890; Thu, 25 Jun 2009 23:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro1I3PGy4SWQ; Thu, 25 Jun 2009 23:05:32 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 24DC23A67DF; Thu, 25 Jun 2009 23:05:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,294,1243828800"; d="scan'208";a="175159817" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Jun 2009 02:05:49 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Jun 2009 02:05:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jun 2009 08:05:29 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for July 2, 2009 Telechat thread-index: Acn15pHq058PO0HKRmCPjjRa2W/jdQAPTQ4g From: "Romascanu, Dan (Dan)" To: , , , "Ops Directorate" Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for July 2, 2009 Telechat X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 06:05:34 -0000 Please find below the preliminary agenda of the 7/2 IESG telechat. Please send me all comments, questions and concerns before 7/1 COB.=20 Thanks and Regards, Dan =20 2.1 WG Submissions 2.1.1 New Item o draft-ietf-avt-rtcpssm-18.txt RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback=20 (Proposed Standard) - 1 of 12=20 Token: Cullen Jennings o draft-ietf-tcpm-rfc2581bis-05.txt TCP Congestion Control (Draft Standard) - 2 of 12=20 Note: Document Shepherd: Wesley Eddy (wesley.m.eddy@nasa.gov). Interop =20 Report: http://www.ietf.org/mail-archive/web/tcpm/current/msg03133.html=20 Token: Lars Eggert o draft-ietf-adslmib-vdsl2-07.txt Definitions of Managed Objects for Very High Speed Digital Subscriber Line=20 2 (VDSL2) (Proposed Standard) - 3 of 12=20 Token: Dan Romascanu o draft-ietf-mipshop-mos-dns-discovery-06.txt Locating IEEE 802.21 Mobility Servers using DNS (Proposed Standard) - 4 of=20 12=20 Note: Document shepherd is Vijay Devarapalli =20 Token: Jari Arkko o draft-ietf-avt-rtp-mps-02.txt RTP Payload Format for Elementary Streams with MPEG Surround multi- channel=20 audio (Proposed Standard) - 5 of 12=20 Token: Cullen Jennings o draft-ietf-dime-qos-attributes-12.txt Quality of Service Attributes for Diameter (Proposed Standard) - 6 of 12=20 Token: Dan Romascanu o draft-ietf-geopriv-civic-address-recommendations-02.txt Considerations for Civic Addresses in PIDF-LO - Guidelines and IANA=20 Registry Definition (BCP) - 7 of 12=20 Token: Cullen Jennings o draft-ietf-sip-body-handling-06.txt Message Body Handling in the Session Initiation Protocol (SIP) (Proposed=20 Standard) - 8 of 12=20 Note: Theo Zourzouvillys is the document shepherd=20 Token: Robert Sparks o draft-ietf-ospf-dynamic-hostname-04.txt Dynamic Hostname Exchange Mechanism for OSPF (Proposed Standard) - 9 of 12=20 Token: Ross Callon o draft-ietf-l2tpext-circuit-status-extensions-04.txt L2TPv3 Extended Circuit Status Values (Proposed Standard) - 10 of 12 Note: Ignacio Goyret is the WG=20 shepherd. for this document..=20 Token: Ralph Droms o draft-ietf-sipcore-subnot-etags-02.txt An Extension to Session Initiation Protocol (SIP) Events for Conditional=20 Event Notification (Proposed Standard) - 11 of 12=20 Note: Dean Willis (dean.willis@softarmor.com) is document shepherd.=20 Token: Robert Sparks o draft-ietf-pwe3-vccv-bfd-05.txt Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit=20 Connectivity Verification (VCCV) (Proposed Standard) - 12 of 12=20 Token: Ralph Droms 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-dusseault-impl-reports-03.txt Guidance on Interoperation and Implementation Reports (BCP) - 1 of 2 Token: Tim Polk o draft-dawkins-nomcom-dont-wait-03.txt Nominating Committee Process: Earlier Announcement of Open Positions and=20 Solicitation of Volunteers (BCP) - 2 of 2=20 Token: Russ Housley 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-geopriv-l7-lcp-ps-09.txt GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and =20 Requirements (Informational) - 1 of 9=20 Token: Cullen Jennings o draft-ietf-pwe3-ms-pw-arch-06.txt An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge=20 (Informational) - 2 of 9=20 Note: David Sinicrope (david.sinicrope@ericsson.com) is the. =20 Document Shepherd for this document.=20 Token: Ralph Droms o draft-ietf-pce-inter-layer-frwk-10.txt Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering =20 (Informational) - 3 of 9=20 Token: Ross Callon o draft-ietf-opsec-blackhole-urpf-04.txt Remote Triggered Black Hole filtering with uRPF (Informational) - 4 of 9=20 Token: Ron Bonica o draft-ietf-dccp-ccid4-04.txt Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4:=20 TCP-Friendly Rate Control for Small Packets (TFRC-SP) (Experimental) - 5 of=20 9=20 Note: Document Shepherd: Pasi Sarolahti (pasi.sarolahti@iki.fi) [was Gorry=20 Fairhurst, but he's not a DCCP chair anymore]=20 Token: Lars Eggert o draft-ietf-smime-new-asn1-05.txt New ASN.1 Modules for CMS and S/MIME (Informational) - 6 of 9=20 Note: Sean Turner (turners@ieca.com) is the document shepherd.=20 Token: Tim Polk o draft-ietf-ancp-security-threats-07.txt Security Threats and Security Requirements for the Access Node Control =20 Protocol (ANCP) (Informational) - 7 of 9=20 Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document =20 shepherd.=20 Token: Ralph Droms o draft-ietf-dccp-quickstart-05.txt Quick-Start for Datagram Congestion Control Protocol (DCCP) (Experimental)=20 - 8 of 9=20 Note: Document shepherd is Pasi Sarolahti =20 Token: Lars Eggert o draft-ietf-pkix-tac-04.txt Traceable Anonymous Certificate (Experimental) - 9 of 9=20 Token: Tim Polk 3.1.2 Returning Item NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-livingood-woundy-p4p-experiences-10.txt Comcast's ISP Experiences In a P4P Technical Trial (Informational) - 1 of 1=20 Token: Lisa Dusseault 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item NONE 3.3.2 Returning Item o draft-irtf-mobopts-location-privacy-solutions-15.txt Mobile IPv6 Location Privacy Solutions (Experimental) - 1 of 1=20 Note: The document shepherd is Basavaraj Patil=20 =20 Token: Jari Arkko 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o STORage Maintenance (storm) - 1 of 1 Token: Lars Eggert 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review o Behavior Engineering for Hindrance Avoidance (behave) - 1 of 3 Token: Magnus Westerlund o IP Flow Information Export (ipfix) - 2 of 3 Token: Dan Romascanu o DNS Extensions (dnsext) - 3 of 3 Token: Ralph Droms 4.2.2 Proposed for Approval o Site Multihoming by IPv6 Intermediation (shim6) - 1 of 3 Token: Jari Arkko o Diameter Maintenance and Extensions (dime) - 2 of 3 Token: Dan Romascanu o Integrated Security Model for SNMP (isms) - 3 of 3 Token: Pasi Eronen From dromasca@avaya.com Thu Jun 25 23:05:59 2009 Return-Path: X-Original-To: aaa-doctors@core3.amsl.com Delivered-To: aaa-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796973A67E5; Thu, 25 Jun 2009 23:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCeSF3V8HzEg; Thu, 25 Jun 2009 23:05:58 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 68C523A67DF; Thu, 25 Jun 2009 23:05:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,294,1243828800"; d="scan'208";a="149653926" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Jun 2009 02:06:13 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 26 Jun 2009 02:06:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jun 2009 08:05:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Integrated Security Model for SNMP (isms) thread-index: Acn15I3WITPoDzoTT1qN/I8FUTkbkwAP5NuQ From: "Romascanu, Dan (Dan)" To: "Ops Directorate" , , , Subject: [AAA-DOCTORS] FW: WG Review: Recharter of Integrated Security Model for SNMP (isms) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 06:05:59 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Friday, June 26, 2009 1:30 AM To: new-work@ietf.org Subject: WG Review: Recharter of Integrated Security Model for SNMP (isms)=20 A modified charter has been submitted for the Integrated Security Model for SNMP (isms) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, July 2, 2009. Integrated Security Model for SNMP (isms) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Last Modified: 2009-06-18 Current Status: Active Working Group Chair(s): Juergen Schoenwaelder Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.ht ml 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 obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing named access control policies, 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 policy name bound to a username, which the VACM extension will use to dynamically populate 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