From jsalowey@cisco.com Sat Oct 9 20:21:47 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F1D3A6403 for ; Sat, 9 Oct 2010 20:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 jXbR6hL8GYdp for ; Sat, 9 Oct 2010 20:21:46 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C50C13A63D3 for ; Sat, 9 Oct 2010 20:21:45 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsFAK/OsExAaMHG/2dsb2JhbACUSY17cZ4Bm2OFRwSEUYVvgwI X-IronPort-AV: E=Sophos;i="4.57,309,1283731200"; d="scan'208";a="369607910" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-1.cisco.com with ESMTP; 10 Oct 2010 03:22:53 +0000 Received: from [10.1.49.68] (hkidc-vpn-client-235-180.cisco.com [10.75.235.180]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9A3Mqv5022997 for ; Sun, 10 Oct 2010 03:22:52 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 9 Oct 2010 20:23:18 -0700 Message-Id: To: emu@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Emu] Agenda Items for IETF 79 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2010 03:21:47 -0000 The EMU meeting is currently scheduled for Wednesday, November 10, = 1510-1610. I would like to focus most of this time on EAP channel = bindings. Please let me know if you have agenda items for the meeting. = Priority will be given to items relevant towards progressing the channel = bindings document. =20 Cheers, Joe= From telemaco.melia@alcatel-lucent.com Tue Oct 12 07:36:22 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828B73A69AF for ; Tue, 12 Oct 2010 07:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.567 X-Spam-Level: X-Spam-Status: No, score=-4.567 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219] 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 U0uBWDF6Goqp for ; Tue, 12 Oct 2010 07:36:21 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 619C93A69BC for ; Tue, 12 Oct 2010 07:36:21 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9CEbQ3d022280 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 12 Oct 2010 16:37:35 +0200 Received: from FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com ([135.120.45.54]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 12 Oct 2010 16:37:17 +0200 From: "MELIA, TELEMACO (TELEMACO)" To: "emu@ietf.org" Date: Tue, 12 Oct 2010 16:37:17 +0200 Thread-Topic: test Thread-Index: ActqGvhGPMElC4LgRJSupkkwh1IHUQ== Message-ID: <3D6C64F2D792B540BAAEBCEF6509363B0EE1E9BCCA@FRMRSSXCHMBSE1.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3D6C64F2D792B540BAAEBCEF6509363B0EE1E9BCCAFRMRSSXCHMBSE_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: [Emu] test X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 14:36:22 -0000 --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE1E9BCCAFRMRSSXCHMBSE_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please ignore telemaco --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE1E9BCCAFRMRSSXCHMBSE_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please ignore
 
telemaco
  --_000_3D6C64F2D792B540BAAEBCEF6509363B0EE1E9BCCAFRMRSSXCHMBSE_-- From bruno.mongazon-cazavet@alcatel-lucent.com Tue Oct 12 07:38:17 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90F93A68FD for ; Tue, 12 Oct 2010 07:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 n8Pe-7jX5ypM for ; Tue, 12 Oct 2010 07:38:16 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 045F63A6823 for ; Tue, 12 Oct 2010 07:38:15 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9CEcY7d006795 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 12 Oct 2010 16:39:27 +0200 Received: from [172.27.205.223] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 12 Oct 2010 16:39:07 +0200 Message-ID: <4CB47306.8020307@alcatel-lucent.com> Date: Tue, 12 Oct 2010 16:39:02 +0200 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Content-Type: multipart/alternative; boundary="------------050705000301070501030908" X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [Emu] I-D Action:draft-mongazon-emu-ip-modes-eap-00.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 14:38:18 -0000 --------------050705000301070501030908 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Connectivity modes Hint for EAP Author(s) : B. Mongazon-Cazavet, Y. El Mghazli Filename : draft-mongazon-emu-ip-modes-eap-00.txt Pages : 8 Date : 2010-10-11 The Extensible Authentication Protocol (EAP) is defined in [RFC3748]. This document defines a mechanism that allows an access network to provide IP connectivity modes hints to an EAP peer -- the end of the link that responds to the authenticator. The purpose is to allow the EAP peer in executing in a reliable and efficient manner the IP connectivity step as soon as the authentication phase completes. This is useful in situations where a peer and the networks it visits support various IP connectivity modes. Without the hint, such a peer might fail or take some time to select a valid IP connectivity mode on the visited network. With the help of the hint, a visited network provides the peer with a list of supported IP connectivity modes and allows it to execute successfully the convenient IP connectivity as soon as the authentication is complete. The hint is particularly useful when users are performing vertical handovers through different network technologies such as wireless ones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mongazon-emu-ip-modes-eap-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-mongazon-emu-ip-modes-eap-00.txt --------------050705000301070501030908 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : IP Connectivity modes Hint for EAP
	Author(s)       : B. Mongazon-Cazavet, Y. El Mghazli
	Filename        : draft-mongazon-emu-ip-modes-eap-00.txt
	Pages           : 8
	Date            : 2010-10-11

The Extensible Authentication Protocol (EAP) is defined in [RFC3748].
This document defines a mechanism that allows an access network to
provide IP connectivity modes hints to an EAP peer -- the end of the
link that responds to the authenticator.  The purpose is to allow the
EAP peer in executing in a reliable and efficient manner the IP
connectivity step as soon as the authentication phase completes.
This is useful in situations where a peer and the networks it visits
support various IP connectivity modes.  Without the hint, such a peer
might fail or take some time to select a valid IP connectivity mode
on the visited network.  With the help of the hint, a visited network
provides the peer with a list of supported IP connectivity modes and
allows it to execute successfully the convenient IP connectivity as
soon as the authentication is complete.  The hint is particularly
useful when users are performing vertical handovers through different
network technologies such as wireless ones.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mongazon-emu-ip-modes-eap-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://ftp.ietf.org/internet-drafts/draft-mongazon-emu-ip-modes-eap-00.txt

--------------050705000301070501030908-- From aland@deployingradius.com Tue Oct 19 01:32:54 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 171BB3A6B8D; Tue, 19 Oct 2010 01:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.117 X-Spam-Level: X-Spam-Status: No, score=-102.117 tagged_above=-999 required=5 tests=[AWL=0.483, 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 gczUKbbFyAH3; Tue, 19 Oct 2010 01:32:49 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id D6DF23A68D5; Tue, 19 Oct 2010 01:32:48 -0700 (PDT) Message-ID: <4CBD580A.1040200@deployingradius.com> Date: Tue, 19 Oct 2010 10:34:18 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "emu@ietf.org" , Sean Turner , iesg-secretary@ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Emu] PROTO write-up for draft-ietf-emu-eaptunnel-req-08.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 08:32:54 -0000 (1.a) Who is the Document Shepherd for this document? ==> Alan DeKok. Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? ==> Yes, and yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? ==> Yes Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? ==> No. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? ==> It may be useful to have a review from someone in the security community who has not been involved in the document development. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? ==> No. For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? ==> No. If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? ==> The consensus shows strong consensus from a number of individuals. The WG as a whole understands and agrees with the document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? ==> No one has threatened an appeal. If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? ==> Yes. The ID Nits are: 1) uses RFC 2119 text without RFC 2119 template. This is intentional, and explained in the document 2) Using non-RFC3330 compliant IP addresses. This appears to be a "false positive", as the document does not use example IP addresses. There are no other reviews necessary. (1.h) Has the document split its references into normative and informative? ==> Yes. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? ==> Yes. The document depends on draft-ietf-emu-chbind. If such normative references exist, what is the strategy for their completion? ==> The channel bindings document is expected to to be published before any tunnel method document. As a result, there appears to be no issue with publishing the tunnel requirements document now. Are there normative references that are downward references, as described in [RFC3967]? ==> No. If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? ==> Yes. There are no IANA considerations. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? ==> This is not applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication and the transport of additional data for other purposes. Working Group Summary The document has had substantial review from a number of working group participants. The working group is ready to start working on protocols. Document Quality The document is a requirements document that has had contributions from Working group participants from different vendors. Discussion in the Working group has resulted in improvements to the document. From iesg-secretary@ietf.org Wed Oct 20 14:34:32 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6C93A6968; Wed, 20 Oct 2010 14:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 I1CscZ4sSWPy; Wed, 20 Oct 2010 14:33:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BDB53A67FB; Wed, 20 Oct 2010 14:33:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no Message-ID: <20101020213302.12851.59312.idtracker@localhost> Date: Wed, 20 Oct 2010 14:33:02 -0700 Cc: emu@ietf.org Subject: [Emu] Last Call: (Requirements for a Tunnel Based EAP Method) to Informational RFC X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 21:34:38 -0000 The IESG has received a request from the EAP Method Update WG (emu) to consider the following document: - 'Requirements for a Tunnel Based EAP Method' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-11-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-emu-eaptunnel-req/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-emu-eaptunnel-req/ No IPR declarations were found that appear related to this I-D. From hartmans@mit.edu Mon Oct 25 14:59:35 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2843A6887 for ; Mon, 25 Oct 2010 14:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.946 X-Spam-Level: X-Spam-Status: No, score=-102.946 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 ZZIVnGpXdZQo for ; Mon, 25 Oct 2010 14:59:34 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id E85853A6867 for ; Mon, 25 Oct 2010 14:59:33 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0BEBC2029B; Mon, 25 Oct 2010 18:01:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2469C40AA; Mon, 25 Oct 2010 18:00:34 -0400 (EDT) From: Sam Hartman To: Joe Salowey References: <2581B072-7FF7-4CAC-9001-D0A2CBBC26E2@cisco.com> Date: Mon, 25 Oct 2010 18:00:34 -0400 In-Reply-To: <2581B072-7FF7-4CAC-9001-D0A2CBBC26E2@cisco.com> (Joe Salowey's message of "Thu, 16 Sep 2010 14:13:43 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emu@ietf.org Subject: Re: [Emu] Comments on draft-ietf-emu-chbind-05 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 21:59:35 -0000 >>>>> "Joe" == Joe Salowey writes: As I discussed with the chairs, I'm making an update, but it's more of an update to address specific detailed comments than to really move the document forward. There have been some issues in my availability, which I believe are very close to being resolved. This work is a dependency for draft-ietf-abfab-gss-eap, which is one of my major projects so I definitely do have the interest to move it forward. I'm sorry that did not happen as much as we'd all like this cycle. Joe> - Protocol definition - there is general consensus that we Joe> should include the protocol definition within this document. I Joe> think it would be good to flesh out the following approach in Joe> the document to see if it meets working group expectations: Joe> define a Channel-Binding-TLV to hold channel binding data; Joe> define channel binding data as diameter AVPs. The protocol Joe> should define attributes for at least one case (probably Joe> 802.11) and provide guidance for creating binds for other Joe> EAP/AAA usages in other follow-on documents. Agreed. Very little happened here. Joe> Detailed comments follow: Joe> 1. Introduction Joe> I think it would be good discuss that the problem is manifested Joe> when the same set of credentials are used to access different Joe> classes or types of services. This is discussed later in Joe> section 4.3, but I believe this to be fundamental to channel Joe> binding problem and should be discussed in the introduction. Joe> When the EAP server is centralized and accessed from different Joe> for different services it typically uses the same set of Joe> credentials to authenticate itself to the peer for each service Joe> so the peer cannot differentiate between services. The server Joe> could also attempt to detect any discrepancy by forcing the Joe> client to use different credentials for each services. Using Joe> different credentials for each different class or type of Joe> service has numerous problems. I added a brief mention in the introduction. Let me know if more is needed. Joe> 2. Section 3 Joe> In the Enterprise network case its not clear to me that channel Joe> bindings alone can alleviate this attack. The peer does not Joe> know which VLAN its traffic is going to, it just knows the Joe> SSID. Likewise the AAA server does not know what VLAN the Joe> authenticator is switching the peers traffic to, it only knows Joe> what it told the authenticator to do, if the authenticator is Joe> compromised, it need not comply. It is possible that this may Joe> be detected by another part of the infrastructure, but this Joe> would involve more than the authenticator, peer and AAA. The unstated assumption here is that the authenticator was only trusted to attach to one of the networks. I.E. separate physical infrastructure for enforcing separate security policy. That's been stated. It does diminish the applicability of the use case. I also added the abfab use case; since that's been chartered it's reasonable to mention here. Joe> One mechanism that deployment use to avoid the "enterprise and Joe> provider" problem today is to use different credentials for Joe> remote access versus enterprise access. This is often not Joe> ideal, but it addresses the problem. mentioned. Joe> 3. Section 4 Joe> It could be possible to use EAP channel bindings to address Joe> some more traditional channel bindings uses cases by carrying Joe> information from the lower layer or encapsulating tunnel in the Joe> transported method. Mentioned. I dread writing or reading "The use of EAP Channel Bindings to Provide RFC 5056 Channel Binding for EAP" (draft-something-eap-chbind-for-chbind-for-eap) I think it's an illustrative example of the difference, but at this time I definitely don't want to get into whether it's a good idea. For your information, I considered and rejected using EAP channel binding for RFC 2743 channel binding (GSS) in draft-ietf-abfab-gss-eap. Using the MSK and an exchange between the peer and authenticator was simpler and didn't depend on the server verifying I1 against I2 for that particular attribute. ABFAB still depends on EAP channel binding in a number of other respects though. Joe> 4. Section 4.2 Joe> This section states that for the system to function the EAP Joe> server has to have access to a local database. THis doesn't Joe> sound right to me. I wouldn't expect many systems would be Joe> designed this way. The accuracy of the AAA attributes would be Joe> verified by the AAA server that hosts the EAP server, but Joe> perhaps this is too fine a distinction for this document. I Joe> would expect any processing of AAA attributes to be done in the Joe> AAA server. I have added text to loosen the architecture in this regard. However, it is very messy if your AAA server and EAP server are decoupled and you want to make the decision in the AAA server. Somehow the EAP server needs to communicate the set of attributes supplied in I1 to the AAA server before generating the success indication. Then, the AAA server needs to make a decision and communicate that decision along with what attributes from I1 were used to the EAP server. The EAP server needs to encapsulate that in EAP and then eventually return the decision. ABFAB participants who have discussed the issue would like to depend on being able to get a list of attributes that were actually considered. I think our reasons are fairly general: without that it's easy for you to run into situations where you fail insecure. We think that will apply to other situations. Where you want to have a security policy on a peer that actually involves the channel binding being checked, you need to depend on this indication. I think that for decoupled EAP and AAA servers the best you can do is as follows. The AAA server has the database. It verifies I2 against the database. The AAA server passes along to the EAP server information on what its requirements are for I1. That way the EAP server can verify I1 and indicate what attributes are used. The "requirements" on I1 may be as simple as a set of attributes that if present in I1 must match one of several possible values enumerated by the AAA server. For some applications it may be sufficient to give a list of attributes that if present MUST match the values found in the AAA message. Joe> 5. Section 4.3 Joe> I don't think the RSNIE containing security parameters is not Joe> currently carried in a AAA attribute. Do we still want to use Joe> this as an example? I don't care much. I left it in until someone provides an example they like more. I don't think anything in this section is actually wrong. Joe> I'm not sure what the 3rd paragraph is getting at. The peer Joe> usually does not have any clue as to what specific VLANs are in Joe> use, so its not clear to me what this is saying. I tried to clean this up. Joe> This section probably should briefly cover that in some cases Joe> it is possible that the EAP-Server is collocated with the Joe> authenticator and AAA is not involved. I did touch on that in the document; I don't think it ended up here. Joe> 6. Section 5.1 Joe> In this section I have the same comment about the EAP Server Joe> accessing the database. I think the EAP server interfaces with Joe> AAA and AAA maintains and process the AAA Joe> attributes. Conceptually the result is the same, so maybe its Joe> not such a big deal. Maybe it would be helpful to describe Joe> that other architectural choices are valid. Separating out the Joe> i2 consistency check form the i1 validation could allow the Joe> consistency of some attributes to be checked on a different AAA Joe> server. I talked about some parts of I2 being checked on a different AAA server. Joe> 7. Section 7 I have no strong opinions about section 7 and 8. I think I'm going to need help/text on these sections from someone who has strong opinions. --Sam From root@core3.amsl.com Mon Oct 25 15:30:09 2010 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 330963A68F1; Mon, 25 Oct 2010 15:30:07 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025223008.330963A68F1@core3.amsl.com> Date: Mon, 25 Oct 2010 15:30:07 -0700 (PDT) Cc: emu@ietf.org Subject: [Emu] I-D Action:draft-ietf-emu-chbind-06.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:30:09 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : Channel Binding Support for EAP Methods Author(s) : S. Hartman, et al. Filename : draft-ietf-emu-chbind-06.txt Pages : 26 Date : 2010-10-25 This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-emu-chbind-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25151557.I-D@ietf.org> --NextPart-- From jsalowey@cisco.com Wed Oct 27 15:02:06 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590D73A680D for ; Wed, 27 Oct 2010 15:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 s89vq5XlJYOo for ; Wed, 27 Oct 2010 15:02:05 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 38DB73A6809 for ; Wed, 27 Oct 2010 15:02:05 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFACc/yEyrR7Ht/2dsb2JhbACTTI13caQ0nCmFSASEV4V8gwg X-IronPort-AV: E=Sophos;i="4.58,248,1286150400"; d="scan'208";a="207851051" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 27 Oct 2010 22:03:55 +0000 Received: from [10.33.248.235] ([10.33.248.235]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9RM3sJQ003959 for ; Wed, 27 Oct 2010 22:03:56 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 27 Oct 2010 15:03:54 -0700 Message-Id: To: emu@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Emu] Draft EMU Agenda X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 22:02:06 -0000 IETF-79 - EMU Working Group WEDNESDAY, November 10, 2010, 1510-1610 Afternoon Session II Garden Ballroom 1 ======================================== 1. Administrivia (note takers, blue sheets, agenda) - 5min 2. EAP Channel Bindings - Sam Hartman - 35min http://tools.ietf.org/html/draft-ietf-emu-chbind-06 3. EAP-TEAM - Glen Zorn - 10Min http://tools.ietf.org/html/draft-zorn-emu-team-01