From hartmans@painless-security.com Mon Jun 3 07:51:05 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D8721F8C1A for ; Mon, 3 Jun 2013 07:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXiYGcApaAFh for ; Mon, 3 Jun 2013 07:51:00 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D97F521F8C08 for ; Mon, 3 Jun 2013 07:50:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 8757A20635 for ; Mon, 3 Jun 2013 10:47:32 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afb1XAMDs-5u for ; Mon, 3 Jun 2013 10:47:31 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Mon, 3 Jun 2013 10:47:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 10FEE440A; Mon, 3 Jun 2013 10:50:58 -0400 (EDT) From: Sam Hartman To: emu@ietf.org Date: Mon, 03 Jun 2013 10:50:58 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [Emu] last call for draft-ietf-abfab-eapapplicability-03 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:51:05 -0000 --=-=-= I wanted to make sure that people in emu are aware that the EAP applicability statement update for application authentication is in IETF last call. --Sam --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from mail.painless-security.com ([unix socket]) by mail.suchdamage.org (Cyrus v2.4.16-Debian-2.4.16-4) with LMTPA; Mon, 03 Jun 2013 09:15:14 -0400 X-Sieve: CMU Sieve 2.4 Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9CFF420584 for ; Mon, 3 Jun 2013 09:15:14 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5QrgqY6YeA4 for ; Mon, 3 Jun 2013 09:15:14 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by mail.painless-security.com (Postfix) with ESMTP for ; Mon, 3 Jun 2013 09:15:14 -0400 (EDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4769F21F9925; Mon, 3 Jun 2013 06:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1370265508; bh=j74W4J7UuMUsZ+PVfs5RLYhJyKdxdwxJM4z5g0eP0Hg=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ncnvNe68txFRkLE51vbKGSpvprZ7ce4/76R0fG8RB0fU6+i960be4ENEgeqwvXPAF rOuEmoWyRJYiaYYsNkAJtCgIuXiY2OAyDOsvU7A7akBO4oHpa0on38E0kypBAO6INE C0milEwTswvnBjJrtOJAYz/6lOt1lEcEjH3+VuwA= X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DF421F98AC; Mon, 3 Jun 2013 06:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtHYNWTYqpWC; Mon, 3 Jun 2013 06:18:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C256621F9808; Mon, 3 Jun 2013 06:18:21 -0700 (PDT) From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130603131818.13138.22141.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 06:18:21 -0700 Cc: abfab@ietf.org Subject: [abfab] Last Call: (Update to the EAP Applicability Statement for ABFAB) to Proposed Standard X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: abfab-bounces@ietf.org Errors-To: abfab-bounces@ietf.org MIME-Version: 1.0 The IESG has received a request from the Application Bridging for Federated Access Beyond web WG (abfab) to consider the following document: - 'Update to the EAP Applicability Statement for ABFAB' as Proposed Standard 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 2013-06-17. 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. Abstract This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-abfab-eapapplicability/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-abfab-eapapplicability/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab --=-=-=-- From turners@ieca.com Tue Jun 4 05:14:53 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D7F21F9A20 for ; Tue, 4 Jun 2013 05:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.776 X-Spam-Level: X-Spam-Status: No, score=-101.776 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_66=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCOjlwJYq80W for ; Tue, 4 Jun 2013 05:14:37 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [67.18.22.76]) by ietfa.amsl.com (Postfix) with ESMTP id 08D1421F9B00 for ; Tue, 4 Jun 2013 03:51:47 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 1016C84133A14; Tue, 4 Jun 2013 05:51:46 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 03A5D841339D1 for ; Tue, 4 Jun 2013 05:51:46 -0500 (CDT) Received: from [173.73.135.101] (port=53337 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Ujoq9-0004G6-Rj for emu@ietf.org; Tue, 04 Jun 2013 05:51:45 -0500 Message-ID: <51ADC6C1.9000904@ieca.com> Date: Tue, 04 Jun 2013 06:51:45 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:53337 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 25 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [Emu] AD review of draft-ietf-emu-crypto-bind-03.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 12:14:53 -0000 I've got no problem initiating an IETF LC on this document, but I do have some nits that need to be fixed before I'll add it to the IESG telechat. Authors please let me know whether you'd like me to initiate the IETF LC now or whether you'd like to submit a revised ID. I only do this because these are minor but will no doubt be called out by somebody on the IESG as a comment and I rather avoid that. 0) abstract: r/[RFC 3748]/RFC 3748 RFC editor would remove the references from the abstract so it's better to do it now or have it pointed out by the gen-art reviewer. 1) move keys words to section 1.1 or make a new section 2. RFC editor will move it so it's better to do it now or else have it pointed out by the gen-art reviewer. 2) s1: r/The Extensible Authentication Protocol [RFC3748] /The Extensible Authentication Protocol (EAP) [RFC3748] Need to re-expand EAP in s1. 3) s3.2.2: delete:Please view in a fixed-width font such as Courier. 4) s3.2.2: The formatting here seems a little off: An attacker can convert an inner authentication using an EAP method to a inner authentication that does not use EAP in some cases. This may avoid cryptographic binding. Converting EAP Inner Authentication An attacker may contact another authentication resource to gain a challenge useful for an inner authentication. Non-EAP Sources of Inner Authentication 5) s3.2.2: r/. a tunnel t2/. A tunnel t2 6) s3.2.4: r/IntroducingEMSK-based Cryptographic Binding /Introducing EMSK-based Cryptographic Binding 7) s7: r/margaret/Margaret From hartmans@mit.edu Tue Jun 4 13:05:56 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE1621F8FDD for ; Tue, 4 Jun 2013 13:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id he0+6Uz370CR for ; Tue, 4 Jun 2013 13:05:51 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4E021F94F9 for ; Tue, 4 Jun 2013 13:04:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9DEFE20639; Tue, 4 Jun 2013 16:01:15 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89Oqx5jYp4js; Tue, 4 Jun 2013 16:01:15 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 4 Jun 2013 16:01:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0EA854498; Tue, 4 Jun 2013 16:04:43 -0400 (EDT) From: Sam Hartman To: Sean Turner References: <51ADC6C1.9000904@ieca.com> Date: Tue, 04 Jun 2013 16:04:42 -0400 In-Reply-To: <51ADC6C1.9000904@ieca.com> (Sean Turner's message of "Tue, 04 Jun 2013 06:51:45 -0400") 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] AD review of draft-ietf-emu-crypto-bind-03.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 20:05:57 -0000 I'll send in a new draft. From jsalowey@cisco.com Tue Jun 4 17:22:54 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFCD21F9A2E for ; Tue, 4 Jun 2013 17:22:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YELagWljYFPK for ; Tue, 4 Jun 2013 17:22:49 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A14AE21F9A35 for ; Tue, 4 Jun 2013 17:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=879; q=dns/txt; s=iport; t=1370391767; x=1371601367; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=vMFJ2SEMy7aBVwnB9Te6Xv2MrQDBp4nMvOT4rC33c/I=; b=J9wPoCZSRasNLVRIAY/cwVtAjri1mNmV7rLwWzL3CGD3njgub143/7kS 3Fz79TeaFXr3uQStoYPgw8Lok4VuBQskpScdnPeO1lUxcn4BljXIDdFVX vNFFZLs6RXNHi9P52eaMXLl69zJpSBW1mz9Xr9LXrbErgq59OrvnQd3bg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAB+ErlGtJXG8/2dsb2JhbABagwkwgVeBHrw1fhZ0giMBAQEDAQEBATc0EAsCARkDAQILFBAhBgsbAggCBBMIh3MDCQYMtHkNiG0EjEmBGYERPoJ0YQOVWI4EhSODD4FxNg X-IronPort-AV: E=Sophos;i="4.87,803,1363132800"; d="scan'208";a="218923825" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 05 Jun 2013 00:22:47 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r550MlKq007371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Jun 2013 00:22:47 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 4 Jun 2013 19:22:46 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: [radext] WGLC #1 for draft-ietf-radext-nai-03 Thread-Index: AQHOYOTBbUfFQ6Z8l0CjibkjFccHJQ== Date: Wed, 5 Jun 2013 00:22:45 +0000 Message-ID: References: <7104B68E-C97B-4847-B0BF-8590ED1810D7@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.222] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Emu] Fwd: [radext] WGLC #1 for draft-ietf-radext-nai-03 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 00:22:55 -0000 Folks on the EMU list may want to comment on this work as well. =20 Cheers, Joe Begin forwarded message: > From: Jouni Korhonen > Subject: [radext] WGLC #1 for draft-ietf-radext-nai-03 > Date: June 3, 2013 9:42:45 PM PDT > To: "radext@ietf.org" > Cc: "radext-chairs@tools.ietf.org" >=20 > Folks, >=20 > This email starts a two week WGLC for draft-ietf-radext-nai-03. The WGLC = end > 18th June 2013 EOB (EEST). We require minimum three reasonable reviews. P= ost > your comments and concerns to the mailing list and also enter your issues= you > want to be _addressed/resolved_ into the issue tracker. >=20 >=20 > - Jouni & Mauricio > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From glenzorn@gmail.com Wed Jun 5 23:26:45 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B963221F83EF; Wed, 5 Jun 2013 23:26:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRIK01RQeyJw; Wed, 5 Jun 2013 23:26:44 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8855021F8A85; Wed, 5 Jun 2013 23:26:42 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id um15so2811719pbc.24 for ; Wed, 05 Jun 2013 23:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LKT1icpdo431l7yypkegnd0LXrE7jXiP77KJHV0KagA=; b=GbpqxpclnlmRf7zrCc83RPfTHji1S67VNrF9yAilqcdIS8urGcOzrmJ3kDJSIw627j 9PJvdgUjwp1S9h7ySRhmx8cctS4VtwXj4qhnVm2dxd2jmfxrbCnmyInh9jb+yLB28cvj 74FJK1xkuMs+c3dMJxqfC82qH942AhjOjKtvJQ+giuobRDAP4Ze7xjxBtgM2wfLZgCuw y4B76umQkwXW5lonIYAGSmQQgdmRllc+GPIA1ZCVkGhEwX+jWtJMpfeN9B4Liok1oLu1 Ko3flF893pdF3nIpcqgtf4BhP/MsOk1iopJMl+hSgZ7py1UZ4us1POlwYlg9auep6e8S LHpA== X-Received: by 10.66.248.68 with SMTP id yk4mr38116437pac.137.1370499996259; Wed, 05 Jun 2013 23:26:36 -0700 (PDT) Received: from [192.168.0.104] (ppp-110-169-211-6.revip5.asianet.co.th. [110.169.211.6]) by mx.google.com with ESMTPSA id b7sm71398690pba.39.2013.06.05.23.26.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 23:26:34 -0700 (PDT) Message-ID: <51B02B96.8080406@gmail.com> Date: Thu, 06 Jun 2013 13:26:30 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <7104B68E-C97B-4847-B0BF-8590ED1810D7@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , The IESG Subject: Re: [Emu] Fwd: [radext] WGLC #1 for draft-ietf-radext-nai-03 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 06:26:46 -0000 On 06/05/2013 07:22 AM, Joseph Salowey (jsalowey) wrote: > Folks on the EMU list may want to comment on this work as well. Really? How about the dime WG, IEEE, 3GPP, 3Gpp2...? It's hard to think of an SDO not effected by this rewrite. > > Cheers, > > Joe > > Begin forwarded message: > >> From: Jouni Korhonen >> Subject: [radext] WGLC #1 for draft-ietf-radext-nai-03 >> Date: June 3, 2013 9:42:45 PM PDT >> To: "radext@ietf.org" >> Cc: "radext-chairs@tools.ietf.org" >> >> Folks, >> >> This email starts a two week WGLC for draft-ietf-radext-nai-03. The WGLC end >> 18th June 2013 EOB (EEST). We require minimum three reasonable reviews. Post >> your comments and concerns to the mailing list and also enter your issues you >> want to be _addressed/resolved_ into the issue tracker. >> >> >> - Jouni & Mauricio >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From aland@deployingradius.com Thu Jun 6 07:00:38 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F88C21F944F; Thu, 6 Jun 2013 07:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8chhsYIrFwd; Thu, 6 Jun 2013 07:00:32 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0B9A21F997A; Thu, 6 Jun 2013 07:00:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8B6902240D6A; Thu, 6 Jun 2013 16:00:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCxCUjLh07YZ; Thu, 6 Jun 2013 16:00:27 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.34.191]) by power.freeradius.org (Postfix) with ESMTPSA id CE1D82240742; Thu, 6 Jun 2013 16:00:26 +0200 (CEST) Message-ID: <51B095FA.9090809@deployingradius.com> Date: Thu, 06 Jun 2013 10:00:26 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Glen Zorn References: <7104B68E-C97B-4847-B0BF-8590ED1810D7@gmail.com> <51B02B96.8080406@gmail.com> In-Reply-To: <51B02B96.8080406@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , The IESG Subject: Re: [Emu] Fwd: [radext] WGLC #1 for draft-ietf-radext-nai-03 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:00:38 -0000 Glen Zorn wrote: > On 06/05/2013 07:22 AM, Joseph Salowey (jsalowey) wrote: > >> Folks on the EMU list may want to comment on this work as well. > > Really? How about the dime WG, IEEE, 3GPP, 3Gpp2...? It's hard to > think of an SDO not effected by this rewrite. As the document says in Section 1: ... This definition of the NAI has no requirements on protocol specifications, implementations, or deployments. ... The intention of the document is to fix egregious errors in RFC 4282. It defines the NAI as a *suggested* identifier. SDOs are free to ignore this standard, as they have done with other RADIUS standards in the past. Alan DeKok. From glenzorn@gmail.com Thu Jun 6 20:47:02 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424BE21F8AF7; Thu, 6 Jun 2013 20:47:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APOPyQeCHs2I; Thu, 6 Jun 2013 20:46:56 -0700 (PDT) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by ietfa.amsl.com (Postfix) with ESMTP id 432D621F848A; Thu, 6 Jun 2013 20:46:56 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w16so4260401pde.37 for ; Thu, 06 Jun 2013 20:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=g4+FXDSPatW/XRYu+z0C3QpPKSI72Ky/GHFGa4YosXE=; b=I69Bo0HgKXUgUJmSqrpthvS4LV3QzHGox4oBX5DimtYjv7pddlBzhcnfmejPuL2M4L uaqyE1ymQkkxLSjclYOXEcNnVgS3kC+2fTez2CwVyJyo+6Jf1CcDi6aIKMRbY4Fabn27 ZJA2tTgxesChXXGjc+ei068j/XOCPdphBC30TKkrtqbJkkXXKXi5Vf653Liaf390GcdA zU85mu0IvxwCHoMobiy3BXXWSO7PzXk6M00uSqs/NBZ1b7eqnF3XYRRd9FIFU5WHtQ2x ud6ErjDJWG7Bgi16nkd+dPoOPVPINVZjqNYyQPl40eQR2yCgYPDeXS/eOh9P5GAfSu8f AkPA== X-Received: by 10.66.11.229 with SMTP id t5mr707471pab.220.1370576816000; Thu, 06 Jun 2013 20:46:56 -0700 (PDT) Received: from [192.168.0.104] (ppp-110-169-218-6.revip5.asianet.co.th. [110.169.218.6]) by mx.google.com with ESMTPSA id wt5sm75526637pbc.38.2013.06.06.20.46.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 20:46:55 -0700 (PDT) Message-ID: <51B157AA.1060700@gmail.com> Date: Fri, 07 Jun 2013 10:46:50 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Alan DeKok References: <7104B68E-C97B-4847-B0BF-8590ED1810D7@gmail.com> <51B02B96.8080406@gmail.com> <51B095FA.9090809@deployingradius.com> In-Reply-To: <51B095FA.9090809@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , The IESG Subject: Re: [Emu] Fwd: [radext] WGLC #1 for draft-ietf-radext-nai-03 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 03:47:02 -0000 On 06/06/2013 09:00 PM, Alan DeKok wrote: > Glen Zorn wrote: >> On 06/05/2013 07:22 AM, Joseph Salowey (jsalowey) wrote: >> >>> Folks on the EMU list may want to comment on this work as well. >> >> Really? How about the dime WG, IEEE, 3GPP, 3Gpp2...? It's hard to >> think of an SDO not effected by this rewrite. > > As the document says in Section 1: > > ... This > definition of the NAI has no requirements on protocol specifications, > implementations, or deployments. ... Thanks, Alan: I guess that I better actually review this, if only to discover what other obvious nonsense it might contain. > > The intention of the document is to fix egregious errors in RFC 4282. > > It defines the NAI as a *suggested* identifier. SDOs are free to > ignore this standard, as they have done with other RADIUS standards in > the past. And yet, it's a Standards Track document; why is that, if it is just a useless suggestion? > > Alan DeKok. > From aland@deployingradius.com Fri Jun 7 06:20:38 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222B021F9273; Fri, 7 Jun 2013 06:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSYhwoMRIGH7; Fri, 7 Jun 2013 06:20:30 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCF821F926E; Fri, 7 Jun 2013 06:20:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 102072240F31; Fri, 7 Jun 2013 15:20:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTgQY2TbgIhm; Fri, 7 Jun 2013 15:20:27 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.34.191]) by power.freeradius.org (Postfix) with ESMTPSA id 4CE7C2240556; Fri, 7 Jun 2013 15:20:27 +0200 (CEST) Message-ID: <51B1DE1D.8000807@deployingradius.com> Date: Fri, 07 Jun 2013 09:20:29 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Glen Zorn References: <7104B68E-C97B-4847-B0BF-8590ED1810D7@gmail.com> <51B02B96.8080406@gmail.com> <51B095FA.9090809@deployingradius.com> <51B157AA.1060700@gmail.com> In-Reply-To: <51B157AA.1060700@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , The IESG Subject: Re: [Emu] Fwd: [radext] WGLC #1 for draft-ietf-radext-nai-03 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 13:20:38 -0000 Glen Zorn wrote: > On 06/06/2013 09:00 PM, Alan DeKok wrote: >> The intention of the document is to fix egregious errors in RFC 4282. >> >> It defines the NAI as a *suggested* identifier. SDOs are free to >> ignore this standard, as they have done with other RADIUS standards in >> the past. > > And yet, it's a Standards Track document; why is that, if it is just a > useless suggestion? So... the entire "Standards Track" process is useless, because some SDOs ignore the documents? What a curious position to hold. Alan DeKok. From hartmans@mit.edu Sun Jun 23 11:51:08 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C5A21F9D70 for ; Sun, 23 Jun 2013 11:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnCW8rTdqUwc for ; Sun, 23 Jun 2013 11:51:01 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D396F21F9D3C for ; Sun, 23 Jun 2013 11:51:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 127AC2014F; Sun, 23 Jun 2013 14:46:54 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_vdlPBfn9hb; Sun, 23 Jun 2013 14:46:53 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Sun, 23 Jun 2013 14:46:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ADE598081C; Sun, 23 Jun 2013 14:50:36 -0400 (EDT) From: Sam Hartman To: Sean Turner References: <51ADC6C1.9000904@ieca.com> Date: Sun, 23 Jun 2013 14:50:36 -0400 In-Reply-To: <51ADC6C1.9000904@ieca.com> (Sean Turner's message of "Tue, 04 Jun 2013 06:51:45 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emu@ietf.org Subject: Re: [Emu] AD review of draft-ietf-emu-crypto-bind-03.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 18:51:08 -0000 >>>>> "Sean" == Sean Turner writes: Sean> 1) move keys words to section 1.1 or make a new section 2. Sean> RFC editor will move it so it's better to do it now or else Sean> have it pointed out by the gen-art reviewer. I thought this was why the note element was introduced into the xml2rfc DTD. I'm kind of tempted to let the RFC editor and xml2rfc authors fight about style and leave as-is. I'm fairly sure I've seen note elements make their way into RFCs. Sean> 4) s3.2.2: The formatting here seems a little off: Sean> An attacker can convert an inner authentication using an EAP Sean> method to a inner authentication that does not use EAP in some Sean> cases. This may avoid cryptographic binding. Sean> Converting EAP Inner Authentication Sean> An attacker may contact another authentication resource to Sean> gain a challenge useful for an inner authentication. Sean> Non-EAP Sources of Inner Authentication This is kind of amusing. Apparently, there are two figures that we never produced artwork for, and you're seeing formatting lossage from that. So, does someone want to volunteer to produce artwork for these figures or shall I remove them and let the text stand on its own? I propose giving the WG a week for someone to step forward. From turners@ieca.com Mon Jun 24 05:42:33 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5961211E812B for ; Mon, 24 Jun 2013 05:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZavGGmJHbmM for ; Mon, 24 Jun 2013 05:42:23 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.93.164.21]) by ietfa.amsl.com (Postfix) with ESMTP id 19D6221F9C44 for ; Mon, 24 Jun 2013 05:42:23 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 3B7C36EFC5301; Mon, 24 Jun 2013 07:41:59 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 2D1306EFC52E1 for ; Mon, 24 Jun 2013 07:41:59 -0500 (CDT) Received: from [173.73.135.101] (port=53552 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Ur669-0004mt-EW; Mon, 24 Jun 2013 07:42:21 -0500 Message-ID: <51C83EAC.3040006@ieca.com> Date: Mon, 24 Jun 2013 08:42:20 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sam Hartman References: <51ADC6C1.9000904@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:53552 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: emu@ietf.org Subject: Re: [Emu] AD review of draft-ietf-emu-crypto-bind-03.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 12:42:33 -0000 On 6/23/13 2:50 PM, Sam Hartman wrote: >>>>>> "Sean" == Sean Turner writes: > > Sean> 1) move keys words to section 1.1 or make a new section 2. > > Sean> RFC editor will move it so it's better to do it now or else > Sean> have it pointed out by the gen-art reviewer. > > I thought this was why the note element was introduced into the xml2rfc > DTD. I'm kind of tempted to let the RFC editor and xml2rfc authors > fight about style and leave as-is. > I'm fairly sure I've seen note elements make their way into RFCs. Ah so this is an xml2rfc thing. Then I'd leave it alone. > Sean> 4) s3.2.2: The formatting here seems a little off: > > Sean> An attacker can convert an inner authentication using an EAP > Sean> method to a inner authentication that does not use EAP in some > Sean> cases. This may avoid cryptographic binding. > > Sean> Converting EAP Inner Authentication > > Sean> An attacker may contact another authentication resource to > Sean> gain a challenge useful for an inner authentication. > > Sean> Non-EAP Sources of Inner Authentication > > This is kind of amusing. Apparently, there are two figures that we > never produced artwork for, and you're seeing formatting lossage from > that. > > So, does someone want to volunteer to produce artwork for these figures > or shall I remove them and let the text stand on its own? > > I propose giving the WG a week for someone to step forward. ack From turners@ieca.com Mon Jun 24 07:57:08 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0849721F8749 for ; Mon, 24 Jun 2013 07:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4--9WXCxM5M for ; Mon, 24 Jun 2013 07:57:01 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.37.21]) by ietfa.amsl.com (Postfix) with ESMTP id CDA7021F9A7B for ; Mon, 24 Jun 2013 07:56:47 -0700 (PDT) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 3F9BA35A5A1CC; Mon, 24 Jun 2013 09:56:42 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 0E3B735A5A104 for ; Mon, 24 Jun 2013 09:56:42 -0500 (CDT) Received: from [173.73.135.101] (port=53765 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Ur8C8-0000cO-Ki for emu@ietf.org; Mon, 24 Jun 2013 09:56:40 -0500 Message-ID: <51C85E28.8030006@ieca.com> Date: Mon, 24 Jun 2013 10:56:40 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:53765 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [Emu] AD review of draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 14:57:08 -0000 Here's my first pass (sitting at SFO killing time). I'd like to like to discuss a couple of things before issuing the IETF LC: 0) s1.2: Is section 1.2 still required? Didn't we publish a requirements draft with all of this information in it? 1) s2: Does phase one include: Authenticating Peer Authenticator ------------------- ------------- +- <- EAP-Request/ | Identity |this? EAP-Response/ | Identity (MyID1) -> +- or does it start here: <- EAP-Request/ EAP-Type=TEAP, V=1 (TEAP Start, S bit set, Authority-ID) Id it's the latter, then maybe: OLD: TEAP authentication occurs in two phases. NEW: TEAP authentication occurs in two phases after the initial EAP request/response exchange. Not sure that my suggestion is right maybe it's between initial eap request and 2) s2.2: I find the figure kind of confusing. Is this same thing: +----------------------------------------------------------+ | +----------------------------------------------------+| | | +------+----+---------------------------------+|| | | | | | +--------------------------+||| | | | | | | +------------------+|||| | CP | EAP | code | id | len | type | type data = TEAP ||||| | | | | | | +------------------+|||| | | | | | +--------------------------+||| | | +------+----+---------------------------------+|| | +----------------------------------------------------+| +----------------------------------------------------------+ Where CP is Carrier Protocol, c = EAP code, i = EAP id, l = EAP length, t = EAP type (and it = TEAP), td = EAP type data and then TEAP is in s4.1? If it's just layers: +------+ | TLS | +------+ | TEAP | +------+ | EAP | +------+ | CP | +------+ mixing the EAP/TEAP wrappers in looks odd to me. I'm not hard over on making this change I'm just trying to understand it. 3) s3.1: I haven't yet found if this is else where in the draft, but if this this check fails then what?: The receiver of the Crypto-Binding TLV MUST verify that the version received in the Crypto-Binding TLV matches the version sent by the receiver in the TEAP version negotiation. Section 3.6.1? 4) s3.2: Okay so any chance we could at least SHOULD a cipher suite with SHA-256? 5) s3.2: This confused me a bit: TEAP implementations MUST support peer authentication during tunnel establishment using the TLS ciphersuites specified in Section 3.2. The EAP peer does not need to authenticate as part of the TLS exchange, but can alternatively be authenticated through additional exchanges carried out in Phase 2. Is this about the TEAP clients supporting TLS server side authentication? I read that and took it mean that both sides had to support certificate-based authentication and if that's the case: TEAP implementations MUST support mutual peer authentication during tunnel establishment using the TLS ciphersuites specified in Section 3.2. if it's just server side: TEAP client's MUST support server-side certificate authentication during tunnel establishment using the TLS ciphersuites specified in Section 3.2. In the next sentence it's the EAP peer is that supposed to be the TEAP peer? 6) s3.2: This section introduces the concept that other TLS extensions can be used. Should this section also include MUST support statements for TLS session tickets and TLS unique? 7) s3.2.2: Paque opaque MUST NOT???? What about the other MUSTs in this section? 8) s3.8.2: Couple of questions: 8.1) How is the pkcs7/10 encoded; is it encapsulated in an media-type (i.e., does it include the content-type, etc headers)? The PKCS#10 is covered in 4.2.17, but what about the PKCS#7. 8.2) Need a reference to where the challenge-password attribute is defined (EST authors did this as well): request challenge-password field ([RFC2985], Section 5.4.1). 8.3) that attribute has a length limit and there's a small chance the tls-unique might be longer. How about adding the same kind of text the EST authors did: The challenge-password field is limited to 255 bytes. If the TLS cipher suite in use produces a longer verify_data than that, then an associated hash algorithm will have to be selected to reduce the verify_data to fit within the challenge password length limit. (Section 7.4.9 of [RFC5246] indicates that no existing cipher suite pose such an issue.) 8.4) What do you think about the following: If tls-unique information is not embedded within the certification request the challenge-password field MUST be empty to indicate that the client did not include the optional channel-binding information (any value submitted is verified by the server as tls-unique information). 8.5) Need some text about verifying the returned certificate back to an authorized TA. Don't want the client to willy-nilly accept the returned certificate. 8.6) Are the CRLs for the issuing CA returned as part of the certs-only message or will the client use the CRLs from the TLS handshake? Should we have some kind of guidance about if the client is going to do this that it SHOULD pull the CRLs/OCSP responses for the CA? 9) s4.2.*: Should the M bits be "OPTiONAL" and "REQUIRED" as opposed to "Optional" and "Mandatory" in order to use RFC 2119 language? 10) s4.2.2: Mandatory is == 1 right? r/Reserved, set to zero (0) /Reserved MUST be set to 1 NITS: 0) abstract: by using the Transport Layer Security (TLS) by using the Transport Layer Security (TLS) protocol 1) replace reference to RFC 2560 with RFC 6960. An updated OCSP RFC was published. 2) s1: this is a little close to marketing: Since the introduction of EAP-FAST [RFC4851] a few years ago, it has been widely adopted in variety of devices and platforms due to its strong security, flexibility and ease of deployment. How about this: Since the introduction of EAP-FAST [RFC4851] a few years ago, it has been widely adopted in variety of devices and platforms. 3) s1.3: r/... may distributed using RFC /... may be distributed using RFC 4) s2: r/TEAP makes use of the TLS enhancements in Ticket Extension [RFC5077] to enable an optimized TLS tunnel session resume while minimizing server state. /TEAP makes use of the TLS SessionTicket Extension [RFC5077], which supports TLS session resumption without requiring session-specific state at the TLS. 5) s2: r/The ticket is referred to as the Protected Access Credential opaque data (or PAC-Opaque). /In this document, the SessionTicket is referred to as the Protected Access Credential opaque data (or PAC-Opaque). 6) s2: r/NewSessionTicket message is being used to /NewSessionTicket message is used to 7) s2.2: r/requires a carrier protocol for transport /requires a transport protocol 8) s2.2: Question: Is there any other way to do this? All conversations in the TEAP protected tunnel MUST be encapsulated in a TLV layer. If it's always going to be encapsulated and that's the only way to do it: All conversations in the TEAP protected tunnel are encapsulated in a TLV layer. 9) s3/s2: The intro in s3 is the same s2 maybe just shorten s3 intro to: The operation of the protocol, including Phase 1 and Phase 2, is the topic of this section. The format of TEAP messages is given in Section 4 and the cryptographic calculations are given in Section 5. 10) s3.1: Again if this is how it is don't need the MUST: If the EAP peer supports this version of the protocol, it responds with an EAP-Response of EAP type=TEAP, and the version number proposed by the TEAP server. 11) s3.2: r/TEAP is based on the TLS handshake /TEAP relies on the TLS handshake 12) s3.2: Are there any other TLS cipher suites that shouldn't be used? NULL? 13) s3.2: How about also pointing to RFC 6961 for the multi-ocsp extension too: For instance, Certificate Status Request extension [RFC6066] and multiple certificate status request extension [RFC6961] can be used to leverage a certificate-status protocol such as OCSP [RFC6960] to check the status of server certificates. 14) s3.2: Could we say this instead to not confuse it with the TLS record protocol: OLD: This message encapsulates one or more TLS records containing the TLS handshake messages. NEW: This message encapsulates one or more TLS handshake messages. 15) s3.2: r/TLS ciphersuites specified in Section 3.2. /TLS ciphersuites specified in this section. 16) s3.2.2:r/from a previous handshake in its ClientHello message /from a previous TLS handshake in its ClientHello message 17) s3.2.3: r/peer can request for a new PAC to be provisioned after /peer can request that a new PAC be provisioned after r/for a new PAC to be provisioned /that a new PAC be provisioned 18) s3.3/3.3.3: Can you add a couple of words about why the two MUST NOTs? It's obvious to me but it might not be to another AD ;) 19) s3.3.2: Should "not recommended" be NOT RECOMMENDED? 20) s3.4.4: OLD: The subject field identifies the entity associated with the public key stored in the subject public key field. The subject name MAY be carried in the subject field and/or the subjectAltName extension.... If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical. NEW: The subject field identifies the entity associated with the public key stored in the subject public key field. The subject name MAY be carried in the subject field and/or the subjectAltName extension. If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical. 21) s3.5: Need to say || means concatenation 22) s3.6.2: SHOULD here? If the TEAP peer detects an error at any point in the TLS layer, the TEAP peer should send a a TEAP response encapsulating a TLS record containing the appropriate TLS alert message. 23) s3.7: You've never seen the 100Mbyte CRLs ;) Note that I know the TSV ADs will probably key on the fragmentation section so I gave them a heads ups so they won't be surprised later. 24) s3.7: Assume this throws off an error? Is there some kind of catch all sentence someplace that I missed that says all MUST NOTs result in an error being thrown? 25) s3.8: Mutual authentication is when both parties are authenticated to each other. I guess the point in the following is that the server-side certificate authentication has already occurred? Mutual authentication results if the peer trusts the provided server certificate belongs to the server; typically this involves both validating the certificate to a trust anchor and confirming the entity named by the certificate is the intended server. 26) s3.8: Is "mutually" the right word shouldn't it just be previously authenticate? Mutual authentication also results when the procedures of Section 3.3 are used to resume a session in which the server was previously mutually authenticated. or should it be: ... a previous session in which the peer and server were mutually authenticated. 27) s3.8: r/EMSK compound MAC present /EMSK compound MAC is present 28) s4.1: r/Reserved (MUST be zero) /Reserved (MUST be zero and ignored upon receipt) 30) s4.2.3/7: r/(Optional)/(OPTIONAL) 31) s4.2.12: r/ 0 - Non-mandatory TLV 1 - Mandatory TLV /0 or 1 matches earlier section or to change s4.2.8 32) s4.2.14: r/optional/OPTIONAL 33) s4.2.15: Need reference for UTF-8: RFC 3629 34) s4.2.16: r/The PKCS#7 TLV is always marked as optional /The PKCS#7 TLV is always marked as OPTIONAL 35) s7.3: Add NOT RECOMMENDED to s1.1. From hzhou@cisco.com Thu Jun 27 13:36:21 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A43D21F9F9A for ; Thu, 27 Jun 2013 13:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKMgwRRs1q0t for ; Thu, 27 Jun 2013 13:36:16 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 04D3021F9F97 for ; Thu, 27 Jun 2013 13:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15285; q=dns/txt; s=iport; t=1372365376; x=1373574976; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=pMgg/RAGtT1W0uYe+W5XNwiTDRTUFTvrn/qn77/YuH8=; b=VK7l/k8HsSq2EnLmbfVrSYaH9ZwD5rXUmws4xKBxRE8ZrjwtDdSwjde8 0DbmXx2BfU8ZYkHtPkTUbgPGjX7CU9b1wy5ND++cqx5jF5+3mB6fG3CUn P8x2cI1n5fK+JTnkDfPPFl03ObMfII4XgMlS198dD8uk32UDBMe8WLtW7 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFANygzFGtJV2d/2dsb2JhbABSCYMJMUm/DIECFnSCIwEBAQECAQEBASQTLQcBDw0BCCIOBjcLJQIEARIIiAAGDLs7BI4TBwMBD3UCOBiCamMDk3OVF4MRgWgBAQcXBho X-IronPort-AV: E=Sophos;i="4.87,954,1363132800"; d="scan'208";a="228142770" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 27 Jun 2013 20:36:15 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5RKaFGf005680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Jun 2013 20:36:15 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 15:36:14 -0500 From: "Hao Zhou (hzhou)" To: Sean Turner , "emu@ietf.org" Thread-Topic: [Emu] AD review of draft-ietf-emu-eap-tunnel-method Thread-Index: AQHOcOshl0d5proYlU2WI12fsfpC85lKGtqA Date: Thu, 27 Jun 2013 20:36:14 +0000 Message-ID: <645B00545719594A88ADF4221831FD382BAD1D@xmb-rcd-x14.cisco.com> In-Reply-To: <51C85E28.8030006@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.130.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <48BC41F0BF488F4D8C07FEC1B0F61D1A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Emu] AD review of draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 20:36:21 -0000 Sean: Thanks for the detailed review. Please see my comments inline below. On 6/24/13 10:56 AM, "Sean Turner" wrote: >Here's my first pass (sitting at SFO killing time). I'd like to like to >discuss a couple of things before issuing the IETF LC: > >0) s1.2: Is section 1.2 still required? Didn't we publish a >requirements draft with all of this information in it? [HZ], We will remove it. > >1) s2: Does phase one include: > > Authenticating Peer Authenticator > ------------------- ------------- >+- <- EAP-Request/ >| Identity >|this? EAP-Response/ >| Identity (MyID1) -> >+- > >or does it start here: > <- EAP-Request/ > EAP-Type=3DTEAP, V=3D1 > (TEAP Start, S bit set, Authority-ID) > >Id it's the latter, then maybe: > >OLD: > > TEAP authentication occurs in two phases. > >NEW: > > TEAP authentication occurs in two phases after the initial EAP > request/response exchange. [HZ] Your suggestion seems to be fine. > >Not sure that my suggestion is right maybe it's between initial eap >request and > >2) s2.2: I find the figure kind of confusing. Is this same thing: > >+----------------------------------------------------------+ >| +----------------------------------------------------+| >| | +------+----+---------------------------------+|| >| | | | | +--------------------------+||| >| | | | | | +------------------+|||| >| CP | EAP | code | id | len | type | type data =3D TEAP ||||| >| | | | | | +------------------+|||| >| | | | | +--------------------------+||| >| | +------+----+---------------------------------+|| >| +----------------------------------------------------+| >+----------------------------------------------------------+ > >Where CP is Carrier Protocol, c =3D EAP code, i =3D EAP id, l =3D EAP leng= th, >t =3D EAP type (and it =3D TEAP), td =3D EAP type data > >and then TEAP is in s4.1? > >If it's just layers: > >+------+ >| TLS | >+------+ >| TEAP | >+------+ >| EAP | >+------+ >| CP | >+------+ > >mixing the EAP/TEAP wrappers in looks odd to me. I'm not hard over on >making this change I'm just trying to understand it. [HZ] Your interpretation is correct and we are using the same layering format as in PEAP and TTLS RFC. > >3) s3.1: I haven't yet found if this is else where in the draft, but if >this this check fails then what?: > > The receiver of the Crypto-Binding TLV MUST verify > that the version received in the Crypto-Binding TLV matches the > version sent by the receiver in the TEAP version negotiation. > >Section 3.6.1? [HZ] Good catch. How about we add a sentence in the end: "If the Crypto-Binding TLV fails to be validated, then it is a fatal error and is handled as described in Section 3.6.3."? > >4) s3.2: Okay so any chance we could at least SHOULD a cipher suite with >SHA-256? [HZ] Ok, Will add a SHOULD for CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA > >5) s3.2: This confused me a bit: > > TEAP implementations MUST support peer authentication during tunnel > establishment using the TLS ciphersuites specified in Section 3.2. > The EAP peer does not need to authenticate as part of the TLS > exchange, but can alternatively be authenticated through additional > exchanges carried out in Phase 2. > >Is this about the TEAP clients supporting TLS server side >authentication? I read that and took it mean that both sides had to >support certificate-based authentication and if that's the case: > > TEAP implementations MUST support mutual peer authentication > during tunnel establishment using the TLS ciphersuites specified > in Section 3.2. [HZ] That's what we mean. Will change to that. > >if it's just server side: > > TEAP client's MUST support server-side certificate authentication > during tunnel establishment using the TLS ciphersuites specified > in Section 3.2. > >In the next sentence it's the EAP peer is that supposed to be the TEAP >peer? [HZ] Will be changed to TEAP Peer. > >6) s3.2: This section introduces the concept that other TLS extensions >can be used. Should this section also include MUST support statements >for TLS session tickets and TLS unique? [HZ] Sure. We mentioned in Section 2 already about the mandatory support for TicketExtension. Will add. > >7) s3.2.2: Paque opaque MUST NOT???? What about the other MUSTs in this >section? [HZ] Not quite understand what you mean. Please explain. > >8) s3.8.2: Couple of questions: > >8.1) How is the pkcs7/10 encoded; is it encapsulated in an media-type >(i.e., does it include the content-type, etc headers)? The PKCS#10 is >covered in 4.2.17, but what about the PKCS#7. [HZ] We will look into this and get back you. > >8.2) Need a reference to where the challenge-password attribute is >defined (EST authors did this as well): request challenge-password field >([RFC2985], Section 5.4.1). [HZ] Will add that. > >8.3) that attribute has a length limit and there's a small chance the >tls-unique might be longer. How about adding the same kind of text the >EST authors did: > > The > challenge-password field is limited to 255 bytes. If the TLS cipher > suite in use produces a longer verify_data than that, then an > associated hash algorithm will have to be selected to reduce the > verify_data to fit within the challenge password length limit. > (Section 7.4.9 of [RFC5246] indicates that no existing cipher suite > pose such an issue.) [HZ] Sounds good. Thanks for the text. > >8.4) What do you think about the following: > > If tls-unique information is not embedded > within the certification request the challenge-password field MUST be > empty to indicate that the client did not include the optional > channel-binding information (any value submitted is verified by the > server as tls-unique information). [HZ] Sounds good. > >8.5) Need some text about verifying the returned certificate back to an >authorized TA. Don't want the client to willy-nilly accept the returned > certificate. [HZ] Good suggestion. Do you have any text to suggest or from EST? > >8.6) Are the CRLs for the issuing CA returned as part of the certs-only >message or will the client use the CRLs from the TLS handshake? Should >we have some kind of guidance about if the client is going to do this >that it SHOULD pull the CRLs/OCSP responses for the CA? [HZ] We are looking into and will get back to you. > >9) s4.2.*: Should the M bits be "OPTiONAL" and "REQUIRED" as opposed to >"Optional" and "Mandatory" in order to use RFC 2119 language? [HZ] The mandatory and optional but in TEAP are bit different than the OPTIONAL and REQUIRED in RFC2119. If the mandatory bit is set, the other peer receiving it MUST understand and handle it, not necessary required to be present in every packet exchange. That's why we keep them in lower case.=20 > >10) s4.2.2: Mandatory is =3D=3D 1 right? [HZ] Yes. There is a typo, should be set to (1). > r/Reserved, set to zero (0) > /Reserved MUST be set to 1 [HZ] Actually, The Reserved bit should be set to 0, not used. > >NITS: > >0) abstract: by using the Transport Layer Security (TLS) > by using the Transport Layer Security (TLS) protocol [HZ] Will do. > >1) replace reference to RFC 2560 with RFC 6960. An updated OCSP RFC was >published. [HZ] Will do > >2) s1: this is a little close to marketing: > > Since the introduction of EAP-FAST [RFC4851] a few years ago, it has > been widely adopted in variety of devices and platforms due to its > strong security, flexibility and ease of deployment. > >How about this: > > Since the introduction of EAP-FAST [RFC4851] a few years ago, it has > been widely adopted in variety of devices and platforms. [HZ] Ok. > >3) s1.3: r/... may distributed using RFC > /... may be distributed using RFC [HZ] Ok. > >4) s2: r/TEAP makes use of the TLS enhancements in Ticket Extension > [RFC5077] to enable an optimized TLS tunnel session resume > while minimizing server state. > /TEAP makes use of the TLS SessionTicket Extension [RFC5077], > which supports TLS session resumption without requiring > session-specific state at the TLS. [HZ] Ok. > >5) s2: r/The ticket is referred to as the Protected Access > Credential opaque data (or PAC-Opaque). > /In this document, the SessionTicket is referred to as the > Protected Access Credential opaque data (or PAC-Opaque). [HZ] Ok. > >6) s2: r/NewSessionTicket message is being used to > /NewSessionTicket message is used to [HZ] Ok. > >7) s2.2: r/requires a carrier protocol for transport > /requires a transport protocol [HZ] Ok. > >8) s2.2: Question: Is there any other way to do this? [HZ] No. > > All conversations in the TEAP protected tunnel MUST be > encapsulated in a TLV layer. > >If it's always going to be encapsulated and that's the only way to do it: > > All conversations in the TEAP protected tunnel are > encapsulated in a TLV layer. [HZ] Will do. > >9) s3/s2: The intro in s3 is the same s2 maybe just shorten s3 intro to: > > The operation of the protocol, including > Phase 1 and Phase 2, is the topic of this section. The format of > TEAP messages is given in Section 4 and the cryptographic > calculations are given in Section 5. [HZ] Ok. > >10) s3.1: Again if this is how it is don't need the MUST: > > If the EAP peer supports this version of the protocol, it > responds with an EAP-Response of EAP type=3DTEAP, and the version > number proposed by the TEAP server. [HZ] Ok. > >11) s3.2: r/TEAP is based on the TLS handshake > /TEAP relies on the TLS handshake [HZ] Ok. > >12) s3.2: Are there any other TLS cipher suites that shouldn't be used? > NULL? [HZ] Ok, Will add. > >13) s3.2: How about also pointing to RFC 6961 for the multi-ocsp >extension too: > > For instance, Certificate > Status Request extension [RFC6066] and multiple certificate > status request extension [RFC6961] can be used to leverage a > certificate-status protocol such as OCSP [RFC6960] to check the > status of server certificates. [HZ} Ok. > >14) s3.2: Could we say this instead to not confuse it with the TLS >record protocol: > >OLD: > > This message > encapsulates one or more TLS records containing the TLS handshake > messages. > >NEW: > > This message > encapsulates one or more TLS handshake > messages. [HZ] ok. > >15) s3.2: r/TLS ciphersuites specified in Section 3.2. > /TLS ciphersuites specified in this section. [HZ] Ok. > >16) s3.2.2:r/from a previous handshake in its ClientHello message > /from a previous TLS handshake in its ClientHello message [HZ] Ok. > >17) s3.2.3: r/peer can request for a new PAC to be provisioned after > /peer can request that a new PAC be provisioned after > r/for a new PAC to be provisioned > /that a new PAC be provisioned [HZ] Ok. > >18) s3.3/3.3.3: Can you add a couple of words about why the two MUST >NOTs? It's obvious to me but it might not be to another AD ;) [HZ] Will do. > >19) s3.3.2: Should "not recommended" be NOT RECOMMENDED? [HZ] Yes. > >20) s3.4.4: > >OLD: > > The subject field identifies the entity associated with the public > key stored in the subject public key field. The subject name MAY > be carried in the subject field and/or the subjectAltName > extension.... If subject naming information is present only in > the subjectAltName extension (e.g., a key bound only to an email > address or URI), then the subject name MUST be an empty sequence > and the subjectAltName extension MUST be critical. > >NEW: > > The subject field identifies the entity associated with the public > key stored in the subject public key field. The subject name MAY > be carried in the subject field and/or the subjectAltName > extension. > > If subject naming information is present only in > the subjectAltName extension (e.g., a key bound only to an email > address or URI), then the subject name MUST be an empty sequence > and the subjectAltName extension MUST be critical. [HZ] Ok. > >21) s3.5: Need to say || means concatenation [HZ] Ok. > >22) s3.6.2: SHOULD here? > > If the TEAP peer detects an error at any point in the TLS layer, the > TEAP peer should send a a TEAP response encapsulating a TLS record > containing the appropriate TLS alert message. [HZ] Yes. > >23) s3.7: You've never seen the 100Mbyte CRLs ;) Note that I know the >TSV ADs will probably key on the fragmentation section so I gave them a >heads ups so they won't be surprised later. > >24) s3.7: Assume this throws off an error? Is there some kind of catch >all sentence someplace that I missed that says all MUST NOTs result in >an error being thrown? [HZ] What is "this?" > >25) s3.8: Mutual authentication is when both parties are authenticated >to each other. I guess the point in the following is that the >server-side certificate authentication has already occurred? > > Mutual authentication results if the peer trusts the provided server > certificate belongs to the server; typically this involves both > validating the certificate to a trust anchor and confirming the > entity named by the certificate is the intended server. [HZ] I guess so. It is contributed text. I think it is talking about making sure server side authentication is happened. > >26) s3.8: Is "mutually" the right word shouldn't it just be previously >authenticate? > > Mutual > authentication also results when the procedures of Section 3.3 are > used to resume a session in which the server was previously mutually > authenticated. > > or should it be: > > ... a previous session in which the peer and server were mutually > authenticated. [HZ] I like the later sentence. > >27) s3.8: r/EMSK compound MAC present > /EMSK compound MAC is present [HZ] Ok. > >28) s4.1: r/Reserved (MUST be zero) > /Reserved (MUST be zero and ignored upon receipt) [HZ] Ok. > >30) s4.2.3/7: r/(Optional)/(OPTIONAL) [HZ] See Comment #10. > >31) s4.2.12: r/ > 0 - Non-mandatory TLV > 1 - Mandatory TLV > /0 or 1 > matches earlier section or to change s4.2.8 [HZ] Ok. > >32) s4.2.14: r/optional/OPTIONAL [HZ] See Comment #10. > >33) s4.2.15: Need reference for UTF-8: RFC 3629 [HZ[ Ok. > >34) s4.2.16: r/The PKCS#7 TLV is always marked as optional > /The PKCS#7 TLV is always marked as OPTIONAL [HZ] See Comment #10. > >35) s7.3: Add NOT RECOMMENDED to s1.1. [HZ] ok. >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www.ietf.org/mailman/listinfo/emu From turners@ieca.com Fri Jun 28 09:41:12 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4C221F9BA2 for ; Fri, 28 Jun 2013 09:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.662 X-Spam-Level: X-Spam-Status: No, score=-101.662 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQk6bgVYkrmG for ; Fri, 28 Jun 2013 09:41:00 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [69.93.164.2]) by ietfa.amsl.com (Postfix) with ESMTP id A1C3C21F9B14 for ; Fri, 28 Jun 2013 09:40:55 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 7795B9D2AEDE5; Fri, 28 Jun 2013 11:40:42 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 5E9BB9D2AED81 for ; Fri, 28 Jun 2013 11:40:42 -0500 (CDT) Received: from [173.73.135.86] (port=50959 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UsbjC-0005Dm-TH; Fri, 28 Jun 2013 11:40:54 -0500 Message-ID: <51CDBC95.10006@ieca.com> Date: Fri, 28 Jun 2013 12:40:53 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Hao Zhou (hzhou)" References: <645B00545719594A88ADF4221831FD382BAD1D@xmb-rcd-x14.cisco.com> In-Reply-To: <645B00545719594A88ADF4221831FD382BAD1D@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.86]:50959 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "emu@ietf.org" Subject: Re: [Emu] AD review of draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:41:12 -0000 I trimmed this down to the ones that weren't resolved. Let me know how those two items end getting resolved. >> 7) s3.2.2: Paque opaque MUST NOT???? What about the other MUSTs in this >> section? > [HZ] Not quite understand what you mean. Please explain. Yeah this one got sent out early ;) Sorry about that. What I meant to write was please add some text about why there are MUST NOTs. If it's just a MUST NOT to make things easier then you'll get push back later but if there's a reason for the MUST NOTs and you include it now it'll smooth the way later. >> 8) s3.8.2: Couple of questions: >> >> 8.1) How is the pkcs7/10 encoded; is it encapsulated in an media-type >> (i.e., does it include the content-type, etc headers)? The PKCS#10 is >> covered in 4.2.17, but what about the PKCS#7. > [HZ] We will look into this and get back you. ack >> 8.5) Need some text about verifying the returned certificate back to an >> authorized TA. Don't want the client to willy-nilly accept the returned >> certificate. > [HZ] Good suggestion. Do you have any text to suggest or from EST? I was thinking simply "The peer MUST verify the returned certificate to an authorized Trust Anchor." >> 8.6) Are the CRLs for the issuing CA returned as part of the certs-only >> message or will the client use the CRLs from the TLS handshake? Should >> we have some kind of guidance about if the client is going to do this >> that it SHOULD pull the CRLs/OCSP responses for the CA? > [HZ] We are looking into and will get back to you. ack >> 10) s4.2.2: Mandatory is == 1 right? > [HZ] Yes. There is a typo, should be set to (1). wfm >> r/Reserved, set to zero (0) >> /Reserved MUST be set to 1 > [HZ] Actually, The Reserved bit should be set to 0, not used. yeah got that one wrong leave it as is >> 24) s3.7: Assume this throws off an error? Is there some kind of catch >> all sentence someplace that I missed that says all MUST NOTs result in >> an error being thrown? > [HZ] What is "this?" This bit: The L flag is set to indicate the presence of the four-octet TLS Message Length field, and MUST be set for the first fragment of a fragmented TLS message or set of messages. It MUST NOT be present for any other message. It's back to providing text about the reason for the MUST NOT. >> 25) s3.8: Mutual authentication is when both parties are authenticated >> to each other. I guess the point in the following is that the >> server-side certificate authentication has already occurred? >> >> Mutual authentication results if the peer trusts the provided server >> certificate belongs to the server; typically this involves both >> validating the certificate to a trust anchor and confirming the >> entity named by the certificate is the intended server. > [HZ] I guess so. It is contributed text. I think it is talking about > making sure server side authentication is happened. yeah okay this seems fine after another read.