From dromasca@avaya.com Fri Feb 11 02:42:05 2011 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 B0DD43A69DD; Fri, 11 Feb 2011 02:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ZeB1vlvIRSRj; Fri, 11 Feb 2011 02:42:04 -0800 (PST) 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 65DE03A694F; Fri, 11 Feb 2011 02:42:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL6hVE2HCzI1/2dsb2JhbACldXOicQKZDIMdgj8Ej0iCcg X-IronPort-AV: E=Sophos;i="4.60,454,1291611600"; d="scan'208";a="231941379" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Feb 2011 05:42:14 -0500 X-IronPort-AV: E=Sophos;i="4.60,454,1291611600"; d="scan'208";a="598383733" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Feb 2011 05:42:13 -0500 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, 11 Feb 2011 11:42:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package of the February 17, 2011 IESG Teleconference Thread-Index: AcvJeSItu6QAh6cmSkyNXunF0bCz7gAXtbug From: "Romascanu, Dan (Dan)" To: , , "YANG Doctors" , , "IETF DNS Directorate" Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package of the February 17, 2011 IESG Teleconference 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, 11 Feb 2011 10:42:05 -0000 Please find below the preliminary agenda of the 2/17 IESG telechat.=20 Please send me your questions, comments and concerns about the document brought up for approval before 2/16 COB.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary .... 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-tsvwg-iana-ports-09 Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry (BCP) Note: AD review comments will be addressed after IETF LC.Gorry Fairhurst (gorry@erg.abdn.ac.uk) is the document shepherd. Token: Alexey Melnikov o draft-ietf-isis-ieee-aq-04 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging (Proposed Standard) Note: David Ward (dward@juniper.net) is the document shepherd. Token: Stewart Bryant o draft-ietf-6man-prefixlen-p2p-01 Using 127-bit IPv6 Prefixes on Inter-Router Links (Proposed Standard) Note: Bob Hinden (bob.hinden@gmail.com) is the document shepherd. Token: Jari Arkko o draft-ietf-isis-reg-purge-00 IS-IS Registry Extension for Purges (Proposed Standard) Note: David Ward (dward@juniper.net) is the document shepherd. Token: Stewart Bryant o draft-ietf-isis-purge-tlv-05 Purge Originator Identification TLV for IS-IS (Proposed Standard) Note: David Ward (dward@juniper.net) is the document shepherd. Token: Stewart Bryant o draft-ietf-pim-registry-04 A Registry for PIM Message Types (Proposed Standard) Note: Mike McBride (mmcbride@cisco.com) is the document shepherd. Token: Adrian Farrel 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items o draft-turner-akf-algs-update-02 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type (Proposed Standard) Note: Sean Turner (turners@ieca.com) is the document Shepherd. Token: Tim Polk o draft-turner-ekpct-algs-update-02 Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type (Proposed Standard) Note: Sean Turner (turners@ieca.com) is the document Shepherd. Token: Tim Polk o draft-arkko-dual-stack-extra-lite-05 Scalable Operation of Address Translators with Per-Interface Bindings (Proposed Standard) Token: Ralph Droms o draft-cheshire-dnsext-special-names-01 Special-Use Domain Names (Proposed Standard) Token: Ralph Droms 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-mipshop-transient-bce-pmipv6-07 Transient Binding for Proxy Mobile IPv6 (Experimental) Note: Vijay Devarapalli (vijay@wichorus.com) is the Document Shepherd Token: Jari Arkko o draft-ietf-pce-inter-layer-req-15 PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering (Informational) Note: Julien Meuric (julien.meuric@orange-ftgroup.com) is the document shepherd. Token: Stewart Bryant o draft-ietf-intarea-shared-addressing-issues-03 Issues with IP Address Sharing (Informational) Note: Julien Laganier (julienl@qualcomm.com) is the document shepherd. Token: Jari Arkko o draft-ietf-ccamp-rwa-wson-framework-12 Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) (Informational) Note: Lou Berger (lberger@labn.net) is the document shepherd. Token: Adrian Farrel 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-mraihi-totp-timebased-07 TOTP: Time-based One-time Password Algorithm (Informational) Note: Hannes Tschofenig (Hannes.Tschofenig@gmx.net) is the document shepherd. Token: Sean Turner o draft-eastlake-sha2b-06 US Secure Hash Algorithms (SHA and SHA based HMAC and HKDF) (Informational) Note: I agreed to sponsor this document since I was the sponsor for RFC 4634. Token: Russ Housley o draft-ymbk-aplusp-08 The A+P Approach to the IPv4 Address Shortage (Experimental) Token: Ron Bonica 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items o draft-irtf-rrg-design-goals-06 Design Goals for Scalable Internet Routing (Informational) Note: Independent submission via IRTF. Joel Halpern (jmh@joelhalpern.com) is the document shepherd. Token: Jari Arkko o draft-irtf-dtnrg-sdnv-08 Using Self-Delimiting Numeric Values in Protocols (Informational) Note: IRTF Submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Ralph Droms o draft-irtf-dtnrg-bundle-security-17 Bundle Security Protocol Specification (Experimental) Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Sean Turner o draft-irtf-dtnrg-bundle-metadata-block-09 Delay-Tolerant Networking Metadata Extension Block (Experimental) Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Peter Saint-Andre o draft-irtf-dtnrg-bundle-previous-hop-block-12 Delay-Tolerant Networking Previous Hop Insertion Block (Experimental) Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Tim Polk o draft-irtf-dtnrg-iana-bp-registries-01 Delay-Tolerant Networks (DTN) Bundle Protocol IANA Registries (Informational) Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd. Token: Jari Arkko From dromasca@avaya.com Wed Feb 16 09:26:21 2011 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 3CC823A6EAC for ; Wed, 16 Feb 2011 09:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 jLaVI8ekABuj for ; Wed, 16 Feb 2011 09:26:20 -0800 (PST) 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 4F0D73A6EB0 for ; Wed, 16 Feb 2011 09:26:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcBAO6XW02HCzI1/2dsb2JhbACXJz+OCXOjAgKZJIVeBI9c X-IronPort-AV: E=Sophos;i="4.60,480,1291611600"; d="scan'208";a="265143713" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Feb 2011 12:26:48 -0500 X-IronPort-AV: E=Sophos;i="4.60,480,1291611600"; d="scan'208";a="601131627" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 16 Feb 2011 12:26:47 -0500 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, 16 Feb 2011 18:26:25 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [abfab] AAA trust establishment Thread-Index: AcvN8W1sxGwTPmxzQTSWvvk4ByzDCQADSKlA From: "Romascanu, Dan (Dan)" To: Subject: [AAA-DOCTORS] FW: [abfab] AAA trust establishment 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, 16 Feb 2011 17:26:21 -0000 FYI, this discussion is happening on the abfab wg list.=20 Dan -----Original Message----- From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of Sam Hartman Sent: Wednesday, February 16, 2011 5:51 PM To: abfab@ietf.org Subject: [abfab] AAA trust establishment I've been thinking about the mail I sent yesterday as well as some discussions within the architecture team. I've also been thinking about Josh's proposed requirement that we specify enough detail about technical trust establishment to get better interoperability than SAML. We've been talking about the importance of proxy behavior throughout the process. Some of that will be local. For example how a proxy near the RP knows that a particular machine is allowed to claim a hostname is a local matter. However, there are significant elements that have real protocol impacts if we're going to have interoperability. first, all of this proxy behavior is inherently optional: today's proxies don't do it. So, as I discussed yesterday we need mechanisms for knowing what proxies have done and what they have not done. Second, when things are decomposed like the host check living in an organization and the realm check living closer to an IDP, then we need to explain how those checks fit together to meet our security guarantees. Also, it is quite obvious that intermediates have important roles to play. The value that federations bring to the ecosystem is managing and negotiatingpolicies and agreements. Some of that feeds into protocol requirements for exchanging what policies are in play, and for allowing the federation to filter (or provide filters) on the behavior of actors. Also, as Josh and I hope to explain in Prague, we believe that a new technical trust mechanism is required for some common ABFAB deployments. All this together suggests to me that we have a lot to think about in terms of the AAA fabric that makes these federations possible. There's a lot of discussion starting to filter into the architecture document. However, I'm now convinced that it goes beyond that. Protocol elements are required.=20 I'm not ready with specific proposals at the moment. What I do think is important is creating some high-bandwidth discussions of the issue to get more than just Josh and I into the right mental space. This is a heads up that I'd like to have these sorts of discussions and a call for interest. --Sam _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab From bernard_aboba@hotmail.com Wed Feb 16 13:33:21 2011 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 DE58D3A6D61 for ; Wed, 16 Feb 2011 13:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 L+15m-NsZWCz for ; Wed, 16 Feb 2011 13:33:20 -0800 (PST) Received: from blu0-omc3-s24.blu0.hotmail.com (blu0-omc3-s24.blu0.hotmail.com [65.55.116.99]) by core3.amsl.com (Postfix) with ESMTP id 8AA8A3A6CB0 for ; Wed, 16 Feb 2011 13:33:20 -0800 (PST) Received: from BLU152-W13 ([65.55.116.73]) by blu0-omc3-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Feb 2011 13:33:45 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_f38851f7-9416-42b9-8e3b-f6b3635492e5_" X-Originating-IP: [131.107.0.98] From: Bernard Aboba To: "dromasca@avaya.com" , Date: Wed, 16 Feb 2011 13:33:45 -0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 16 Feb 2011 21:33:45.0607 (UTC) FILETIME=[30ACE170:01CBCE21] Subject: Re: [AAA-DOCTORS] FW: [abfab] AAA trust establishment 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, 16 Feb 2011 21:33:22 -0000 --_f38851f7-9416-42b9-8e3b-f6b3635492e5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Changes to AAA protocols are out of scope of the ABFAB charter=2C right? > Date: Wed=2C 16 Feb 2011 18:26:25 +0100 > From: dromasca@avaya.com > To: aaa-doctors@ietf.org > Subject: [AAA-DOCTORS] FW: [abfab] AAA trust establishment >=20 > FYI=2C this discussion is happening on the abfab wg list.=20 >=20 > Dan >=20 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Wednesday=2C February 16=2C 2011 5:51 PM > To: abfab@ietf.org > Subject: [abfab] AAA trust establishment >=20 >=20 >=20 > I've been thinking about the mail I sent yesterday as well as some > discussions within the architecture team. I've also been thinking about > Josh's proposed requirement that we specify enough detail about > technical trust establishment to get better interoperability than SAML. >=20 > We've been talking about the importance of proxy behavior throughout the > process. Some of that will be local. For example how a proxy near the > RP knows that a particular machine is allowed to claim a hostname is a > local matter. >=20 > However=2C there are significant elements that have real protocol impacts > if we're going to have interoperability. >=20 > first=2C all of this proxy behavior is inherently optional: today's > proxies don't do it. So=2C as I discussed yesterday we need mechanisms > for knowing what proxies have done and what they have not done. >=20 > Second=2C when things are decomposed like the host check living in an > organization and the realm check living closer to an IDP=2C then we need > to explain how those checks fit together to meet our security > guarantees. Also=2C it is quite obvious that intermediates have importan= t > roles to play. The value that federations bring to the ecosystem is > managing and negotiating policies and agreements. Some of that feeds > into protocol requirements for exchanging what policies are in play=2C an= d > for allowing the federation to filter (or provide filters) on the > behavior of actors. >=20 > Also=2C as Josh and I hope to explain in Prague=2C we believe that a new > technical trust mechanism is required for some common ABFAB deployments. >=20 > All this together suggests to me that we have a lot to think about in > terms of the AAA fabric that makes these federations possible. There's a > lot of discussion starting to filter into the architecture document. > However=2C I'm now convinced that it goes beyond that. > Protocol elements are required.=20 >=20 > I'm not ready with specific proposals at the moment. What I do think is > important is creating some high-bandwidth discussions of the issue to > get more than just Josh and I into the right mental space. >=20 > This is a heads up that I'd like to have these sorts of discussions and > a call for interest. >=20 > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors = --_f38851f7-9416-42b9-8e3b-f6b3635492e5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Changes to AAA protocols are out of scope of the ABFAB charter=2C right?
>=3B Date: Wed=2C 16 Feb 2011 18:26:25 +0100
>=3B From: dromasc= a@avaya.com
>=3B To: aaa-doctors@ietf.org
>=3B Subject: [AAA-DOCT= ORS] FW: [abfab] AAA trust establishment
>=3B
>=3B FYI=2C this = discussion is happening on the abfab wg list.
>=3B
>=3B Dan
= >=3B
>=3B -----Original Message-----
>=3B From: abfab-bounces@= ietf.org [mailto:abfab-bounces@ietf.org] On Behalf
>=3B Of Sam Hartman=
>=3B Sent: Wednesday=2C February 16=2C 2011 5:51 PM
>=3B To: abf= ab@ietf.org
>=3B Subject: [abfab] AAA trust establishment
>=3B >=3B
>=3B
>=3B I've been thinking about the mail I sent yes= terday as well as some
>=3B discussions within the architecture team. = I've also been thinking about
>=3B Josh's proposed requirement that we= specify enough detail about
>=3B technical trust establishment to get= better interoperability than SAML.
>=3B
>=3B We've been talking= about the importance of proxy behavior throughout the
>=3B process. = Some of that will be local. For example how a proxy near the
>=3B RP k= nows that a particular machine is allowed to claim a hostname is a
>= =3B local matter.
>=3B
>=3B However=2C there are significant ele= ments that have real protocol impacts
>=3B if we're going to have inte= roperability.
>=3B
>=3B first=2C all of this proxy behavior is i= nherently optional: today's
>=3B proxies don't do it. So=2C as I disc= ussed yesterday we need mechanisms
>=3B for knowing what proxies have = done and what they have not done.
>=3B
>=3B Second=2C when thing= s are decomposed like the host check living in an
>=3B organization an= d the realm check living closer to an IDP=2C then we need
>=3B to expl= ain how those checks fit together to meet our security
>=3B guarantees= . Also=2C it is quite obvious that intermediates have important
>=3B = roles to play. The value that federations bring to the ecosystem is
>= =3B managing and negotiating policies and agreements. Some of that feeds>=3B into protocol requirements for exchanging what policies are in pla= y=2C and
>=3B for allowing the federation to filter (or provide filter= s) on the
>=3B behavior of actors.
>=3B
>=3B Also=2C as Jos= h and I hope to explain in Prague=2C we believe that a new
>=3B techni= cal trust mechanism is required for some common ABFAB deployments.
>= =3B
>=3B All this together suggests to me that we have a lot to think= about in
>=3B terms of the AAA fabric that makes these federations po= ssible. There's a
>=3B lot of discussion starting to filter into the a= rchitecture document.
>=3B However=2C I'm now convinced that it goes b= eyond that.
>=3B Protocol elements are required.
>=3B
>=3B= I'm not ready with specific proposals at the moment. What I do think is>=3B important is creating some high-bandwidth discussions of the issue= to
>=3B get more than just Josh and I into the right mental space.>=3B
>=3B This is a heads up that I'd like to have these sorts of = discussions and
>=3B a call for interest.
>=3B
>=3B --Sam>=3B _______________________________________________
>=3B abfab ma= iling list
>=3B abfab@ietf.org
>=3B https://www.ietf.org/mailman/= listinfo/abfab
>=3B _______________________________________________>=3B AAA-DOCTORS mailing list
>=3B AAA-DOCTORS@ietf.org
>=3B h= ttps://www.ietf.org/mailman/listinfo/aaa-doctors
= --_f38851f7-9416-42b9-8e3b-f6b3635492e5_-- From dromasca@avaya.com Thu Feb 17 03:39:38 2011 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 A51103A6C9B for ; Thu, 17 Feb 2011 03:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 pasvHjnnUjH3 for ; Thu, 17 Feb 2011 03:39:37 -0800 (PST) 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 0A77C3A6C87 for ; Thu, 17 Feb 2011 03:39:34 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUBAGaXXE3GmAcF/2dsb2JhbACCSZUEDo49c6JDApkbhV4Ej2SCdQ X-IronPort-AV: E=Sophos;i="4.60,485,1291611600"; d="scan'208,217";a="265283047" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Feb 2011 06:40:04 -0500 X-IronPort-AV: E=Sophos;i="4.60,485,1291611600"; d="scan'208,217";a="583405636" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Feb 2011 06:40:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBCE97.681FF899" Date: Thu, 17 Feb 2011 12:39:56 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] FW: [abfab] AAA trust establishment Thread-Index: AcvOITJD5abVR3AiQ0Kpett5s2xm6wAc6g1Q References: From: "Romascanu, Dan (Dan)" To: "Bernard Aboba" , Subject: Re: [AAA-DOCTORS] FW: [abfab] AAA trust establishment 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, 17 Feb 2011 11:39:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBCE97.681FF899 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Changes to existing protocols are to be coordinated with the WGs in charge. Development of new protocols can be considered.=20 =20 =20 The relevant paragraphs in the charter http://datatracker.ietf.org/wg/abfab/charter/ seem to be:=20 =20 > Other than a change to its applicability statement and the development of=20 EAP mechanisms, the working group may not change EAP, RADIUS or Diameter without establishing consensus with the appropriate community within the IETF.=20 ... > Concerns have been raised that additional work is required in keying AAA=20 associations in a federated environment. The working group is chartered=20 to explore these concerns and if needed, specify protocols that use=20 existing AAA key management mechanisms to address these concerns. =20 Dan =20 ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Wednesday, February 16, 2011 11:34 PM To: Romascanu, Dan (Dan); aaa-doctors@ietf.org Subject: RE: [AAA-DOCTORS] FW: [abfab] AAA trust establishment =09 =09 Changes to AAA protocols are out of scope of the ABFAB charter, right? =09 > Date: Wed, 16 Feb 2011 18:26:25 +0100 > From: dromasca@avaya.com > To: aaa-doctors@ietf.org > Subject: [AAA-DOCTORS] FW: [abfab] AAA trust establishment >=20 > FYI, this discussion is happening on the abfab wg list.=20 >=20 > Dan >=20 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Wednesday, February 16, 2011 5:51 PM > To: abfab@ietf.org > Subject: [abfab] AAA trust establishment >=20 >=20 >=20 > I've been thinking about the mail I sent yesterday as well as some > discussions within the architecture team. I've also been thinking about > Josh's proposed requirement that we specify enough detail about > technical trust establishment to get better interoperability than SAML. >=20 > We've been talking about the importance of proxy behavior throughout the > process. Some of that will be local. For example how a proxy near the > RP knows that a particular machine is allowed to claim a hostname is a > local matter. >=20 > However, there are significant elements that have real protocol impacts > if we're going to have interoperability. >=20 > first, all of this proxy behavior is inherently optional: today's > proxies don't do it. So, as I discussed yesterday we need mechanisms > for knowing what proxies have done and what they have not done. >=20 > Second, when things are decomposed like the host check living in an > organization and the realm check living closer to an IDP, then we need > to explain how those checks fit together to meet our security > guarantees. Also, it is quite obvious that intermediates have important > roles to play. The value that federations bring to the ecosystem is > managing and negotiating policies and agreements. Some of that feeds > into protocol requirements for exchanging what policies are in play, and > for allowing the federation to filter (or provide filters) on the > behavior of actors. >=20 > Also, as Josh and I hope to explain in Prague, we believe that a new > technical trust mechanism is required for some common ABFAB deployments. >=20 > All this together suggests to me that we have a lot to think about in > terms of the AAA fabric that makes these federations possible. There's a > lot of discussion starting to filter into the architecture document. > However, I'm now convinced that it goes beyond that. > Protocol elements are required.=20 >=20 > I'm not ready with specific proposals at the moment. What I do think is > important is creating some high-bandwidth discussions of the issue to > get more than just Josh and I into the right mental space. >=20 > This is a heads up that I'd like to have these sorts of discussions and > a call for interest. >=20 > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > _______________________________________________ > AAA-DOCTORS mailing list > AAA-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/aaa-doctors =09 ------_=_NextPart_001_01CBCE97.681FF899 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Changes to=20 existing protocols are to be coordinated with the WGs in charge. = Development of=20 new protocols can be considered. 
 =20
 
The relevant=20 paragraphs in the charter http://datatracker= .ietf.org/wg/abfab/charter/ seem=20 to be:
 
>=20 Other than a change to its = applicability=20 statement and the development of
EAP mechanisms, the working group = may not=20 change EAP, RADIUS or Diameter
without establishing consensus with = the=20 appropriate community within the
IETF.

...

>=20 Concerns have been raised that additional work is required in = keying AAA=20
associations in a federated environment. The working group is = chartered=20
to explore these concerns and if needed, specify protocols that use=20
existing AAA key management mechanisms to address these=20 concerns.

 

Dan

 


From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: Wednesday, = February 16,=20 2011 11:34 PM
To: Romascanu, Dan (Dan);=20 aaa-doctors@ietf.org
Subject: RE: [AAA-DOCTORS] FW: [abfab] = AAA=20 trust establishment

Changes to AAA protocols are out of scope of the ABFAB = charter,=20 right?

> Date: Wed, 16 Feb 2011 18:26:25 +0100
> From: = dromasca@avaya.com
> To: aaa-doctors@ietf.org
> Subject:=20 [AAA-DOCTORS] FW: [abfab] AAA trust establishment
>
> = FYI, this=20 discussion is happening on the abfab wg list.
>
> = Dan
>=20
> -----Original Message-----
> From: = abfab-bounces@ietf.org=20 [mailto:abfab-bounces@ietf.org] On Behalf
> Of Sam = Hartman
> Sent:=20 Wednesday, February 16, 2011 5:51 PM
> To: = abfab@ietf.org
>=20 Subject: [abfab] AAA trust establishment
>
>
> =
>=20 I've been thinking about the mail I sent yesterday as well as = some
>=20 discussions within the architecture team. I've also been thinking=20 about
> Josh's proposed requirement that we specify enough = detail=20 about
> technical trust establishment to get better = interoperability=20 than SAML.
>
> We've been talking about the importance of = proxy=20 behavior throughout the
> process. Some of that will be local. = For=20 example how a proxy near the
> RP knows that a particular = machine is=20 allowed to claim a hostname is a
> local matter.
> =
>=20 However, there are significant elements that have real protocol=20 impacts
> if we're going to have interoperability.
> =
>=20 first, all of this proxy behavior is inherently optional: = today's
>=20 proxies don't do it. So, as I discussed yesterday we need = mechanisms
>=20 for knowing what proxies have done and what they have not = done.
>=20
> Second, when things are decomposed like the host check living = in=20 an
> organization and the realm check living closer to an IDP, = then we=20 need
> to explain how those checks fit together to meet our=20 security
> guarantees. Also, it is quite obvious that = intermediates have=20 important
> roles to play. The value that federations bring to = the=20 ecosystem is
> managing and negotiating policies and agreements. = Some of=20 that feeds
> into protocol requirements for exchanging what = policies are=20 in play, and
> for allowing the federation to filter (or provide = filters) on the
> behavior of actors.
>
> Also, as = Josh and=20 I hope to explain in Prague, we believe that a new
> technical = trust=20 mechanism is required for some common ABFAB deployments.
> =
> All=20 this together suggests to me that we have a lot to think about = in
>=20 terms of the AAA fabric that makes these federations possible. There's = a
> lot of discussion starting to filter into the architecture=20 document.
> However, I'm now convinced that it goes beyond = that.
>=20 Protocol elements are required.
>
> I'm not ready with = specific=20 proposals at the moment. What I do think is
> important is = creating some=20 high-bandwidth discussions of the issue to
> get more than just = Josh and=20 I into the right mental space.
>
> This is a heads up = that I'd=20 like to have these sorts of discussions and
> a call for=20 interest.
>
> --Sam
>=20 _______________________________________________
> abfab mailing=20 list
> abfab@ietf.org
>=20 https://www.ietf.org/mailman/listinfo/abfab
>=20 _______________________________________________
> AAA-DOCTORS = mailing=20 list
> AAA-DOCTORS@ietf.org
>=20 = https://www.ietf.org/mailman/listinfo/aaa-doctors
= ------_=_NextPart_001_01CBCE97.681FF899-- From dromasca@avaya.com Thu Feb 24 23:17:00 2011 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 002833A6925; Thu, 24 Feb 2011 23:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Gfmss0Kc94Ww; Thu, 24 Feb 2011 23:16:59 -0800 (PST) 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 D4FA13A692F; Thu, 24 Feb 2011 23:16:54 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADrmZk2HCzI1/2dsb2JhbACmO3SkBgKZMYJ/gmEEj3U X-IronPort-AV: E=Sophos;i="4.62,224,1297054800"; d="scan'208";a="234108342" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Feb 2011 02:17:44 -0500 X-IronPort-AV: E=Sophos;i="4.62,224,1297054800"; d="scan'208";a="605294388" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Feb 2011 02:17:43 -0500 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, 25 Feb 2011 08:17:30 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the March 3, 2011 Telechat Thread-Index: AcvUf1egQMDPTbyiQ9qe5Om3iB5y+gAOc9nA From: "Romascanu, Dan (Dan)" To: "IETF DNS Directorate" , , , , "YANG Doctors" Subject: [AAA-DOCTORS] FW: PRELIMINARY Agenda and Package for the March 3, 2011 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, 25 Feb 2011 07:17:00 -0000 =20 Please find below the preliminary agenda of the 3/3 IESG telechat. Please send me your comments, questions and concerns related to the documents and WG charters on the agenda before 3/2 COB.=20 Thanks and Regards, Dan -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary ... 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-netconf-rfc4742bis-07 Using the NETCONF Configuration Protocol over Secure Shell (SSH) (Proposed Standard) Note: Mehmet Ersue (mehmet.ersue@nsn.com) is the document shepherd. Token: Dan Romascanu o draft-ietf-netconf-4741bis-09 Network Configuration Protocol (NETCONF) (Proposed Standard) Note: Bert Wijnen (bertietf@bwijnen.net) is the document shepherd. Token: Dan Romascanu o draft-ietf-hokey-ldn-discovery-06 The Local Domain Name DHCPv6 Option (Proposed Standard) Note: The document shepherd is Tina Tsou Token: Tim Polk o draft-ietf-payload-rfc4695-bis-01 RTP Payload Format for MIDI (Proposed Standard) Note: Roni Even (even.roni@huawei.com) is the document shepherd. Token: Robert Sparks 2.1.2 Returning Items o draft-ietf-sipcore-199-05 Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog (Proposed Standard) Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document shepherd. Token: Robert Sparks 2.2 Individual Submissions 2.2.1 New Items o draft-holsten-about-uri-scheme-06 The 'about' URI scheme (Proposed Standard) Token: Alexey Melnikov o draft-bryan-metalinkhttp-20 Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP Header Fields (Proposed Standard) Token: Alexey Melnikov Was deferred by Alexey Melnikov on 2011-02-17 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-speermint-voipthreats-07 Session Peering for Multimedia Interconnect (SPEERMINT) Security Threats and Suggested Countermeasures (Informational) Note: Jason Livingood (Jason_Livingood@cable.comcast.com) is the document shepherd. Token: Gonzalo Camarillo o draft-ietf-6lowpan-usecases-09 Design and Application Spaces for 6LoWPANs (Informational) Note: Geoff Mulligan (geoff.ietf@mulligan.com)is the document shepherd. Token: Ralph Droms o draft-ietf-hip-over-hip-05 Host Identity Protocol Signaling Message Transport Modes (Experimental) Note: Gonzalo Camarillo (gonzalo.camarillo@ericsson.com) is the document shepherd Token: Ralph Droms o draft-ietf-hip-cert-09 Host Identity Protocol Certificates (Experimental) Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document shepherd. Token: Ralph Droms 3.1.2 Returning Items o draft-ietf-v6ops-v6-in-mobile-networks-03 Mobile Networks Considerations for IPv6 Deployment (Informational) Note: Fred Baker (fred@cisco.com) is the document shepherd. Token: Ron Bonica 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-mraihi-mutual-oath-hotp-variants-13 OCRA: OATH Challenge-Response Algorithms (Informational) Note: Hannes Tschofenig (Hannes.Tschofenig@gmx.net) is the document shepherd. Token: Sean Turner Was deferred by Tim Polk on 2011-02-08 o draft-meadors-multiple-attachments-ediint-10 Multiple Attachments for EDIINT (Informational) Token: Alexey Melnikov o draft-josefsson-rc4-test-vectors-02 Test vectors for the stream cipher RC4 (Informational) Note: Simon Josefsson (simon@josefsson.org) is the Document Shepherd. Token: Sean Turner o draft-mrw-nat66-07 IPv6-to-IPv6 Network Prefix Translation (Experimental) Token: Ron Bonica 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items NONE 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Verification Involving PSTN Reachability (vipr) Token: Robert Sparks o Address Resolution for Massive numbers of hosts in the Data center (armd) Token: Ron Bonica 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o DNS Extensions (dnsext) Token: Ralph Droms 4.2.2 Proposed for Approval NONE ------------------------------------------------------------------------ From dromasca@avaya.com Mon Feb 28 08:52:41 2011 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 7984A3A6B2F for ; Mon, 28 Feb 2011 08:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 4lxgXxJXQ4w7 for ; Mon, 28 Feb 2011 08:52:40 -0800 (PST) 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 412AD3A6A04 for ; Mon, 28 Feb 2011 08:52:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssIAH5ha03GmAcF/2dsb2JhbACYMopGg090o00CmQGFYQSPdQ X-IronPort-AV: E=Sophos;i="4.62,240,1297054800"; d="scan'208";a="267041900" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Feb 2011 11:53:40 -0500 X-IronPort-AV: E=Sophos;i="4.62,240,1297054800"; d="scan'208";a="587822655" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Feb 2011 11:53:40 -0500 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: Mon, 28 Feb 2011 17:53:22 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AAA-Doctors Lunch in Prague Thread-Index: AcvXaAIwi81oj/xoQxKRWgQOdSKo3w== From: "Romascanu, Dan (Dan)" To: Subject: [AAA-DOCTORS] AAA-Doctors Lunch in Prague 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: Mon, 28 Feb 2011 16:52:41 -0000 Hi, The AAA-Doctors work lunch will take place in Prague as at all IETF meetings during the Thursday lunch break. The date is this time Thursday 3/31. The location will be announced close to the meeting. Please confirm participation. If you have any items that you would like to be discussed over this lunch please let me know.=20 Regards, Dan