From hartmans@mit.edu Fri Mar 1 07:15:44 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 D50EC11E80A2 for ; Fri, 1 Mar 2013 07:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.742 X-Spam-Level: X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqaQD5tFrHyt for ; Fri, 1 Mar 2013 07:15:44 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4834811E809C for ; Fri, 1 Mar 2013 07:15:44 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 539E120115; Fri, 1 Mar 2013 10:10:44 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1071A447B; Fri, 1 Mar 2013 10:15:40 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <029201ce1565$32d03870$9870a950$@augustcellars.com> Date: Fri, 01 Mar 2013 10:15:40 -0500 In-Reply-To: <029201ce1565$32d03870$9870a950$@augustcellars.com> (Jim Schaad's message of "Wed, 27 Feb 2013 19:39:18 -0800") 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: 'Sam Hartman' , emu@ietf.org Subject: Re: [Emu] Comments on 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, 01 Mar 2013 15:15:45 -0000 >>>>> "Jim" == Jim Schaad writes: >> There doesn't seem to be a way for a server to request channel >> binding. If that's true we should probably add the following: >> Since a server cannot indicate a desire for channel binding, >> clients that Jim> have >> channel binding data to send SHOULD include channel-binding TLV >> in a request-action TLV if mutual authentication (section 3.11) >> succeeded. Jim> If this is true - then I agree it is a flaw. Jim> I think that one could send a channel-binding TLV with no data Jim> to request that a client send channel binding data back. This Jim> should not cause any significant problems. If that's permitted then it should be explicitly documented. I think that if this is permitted, everyone who implements channel binding needs to be required to support this. Jim> One could then have Channel-binding server->peer - no data Jim> Channel-binding peer->server - here is my data Channel-binding Jim> server->peer - here is my data Again, let's document this if it is permitted. It's clear the spec is unclear if you and I read if differently. Jim> However I believe that the client can initiate this by just Jim> sending the channel binding TLV in the clear and not in a Jim> request if the client wants to initiate it. My reading is that you cannot send a channel binding outside of a request. This needs clarification as well if we're reading it differently. From hartmans@mit.edu Fri Mar 1 09:03:32 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 7DD5E21E80D3 for ; Fri, 1 Mar 2013 09:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.737 X-Spam-Level: X-Spam-Status: No, score=-102.737 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dciGg4T6Y9Gd for ; Fri, 1 Mar 2013 09:03:32 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D8C4D21E808A for ; Fri, 1 Mar 2013 09:03:31 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 273D320115; Fri, 1 Mar 2013 11:58:31 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D010D447B; Fri, 1 Mar 2013 12:03:28 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <511AABCF.8020807@deployingradius.com> <512E306F.7060205@deployingradius.com> Date: Fri, 01 Mar 2013 12:03:28 -0500 In-Reply-To: <512E306F.7060205@deployingradius.com> (Alan DeKok's message of "Wed, 27 Feb 2013 11:12:31 -0500") 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] Last call on 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, 01 Mar 2013 17:03:32 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Alan DeKok wrote: >> This is a WG last call on the draft-ietf-emu-eap-tunnel-method >> document. Please post reviews, comments, feedback, etc. to this >> list. >> >> The WG last call will last two weeks, until February 26. >> >> If there have been no substantive comments or issues, we will >> take the document to IETF last call. Minor editorial issues can >> be resolved then. >> Alan> There have been no comments during the last call period. We can Alan> therefore close the WG last call, and move the document on to Alan> the next step. Uh, hello? I raised some comments in a message dated Feburary 23 with subject "Comments on draft-ietf-emu-eap-tunnel-method," , a few of which I consider substantive and would appreciate a response to those comments. From aland@deployingradius.com Fri Mar 1 09:16:22 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 60E9721F92EC for ; Fri, 1 Mar 2013 09:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vv1nqS3Oh6Sb for ; Fri, 1 Mar 2013 09:16:21 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id BBDAE21F92B9 for ; Fri, 1 Mar 2013 09:16:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 55BE82240D8B; Fri, 1 Mar 2013 18:16:21 +0100 (CET) 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 uIn50vbgjFBZ; Fri, 1 Mar 2013 18:16:17 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.60]) by power.freeradius.org (Postfix) with ESMTPSA id 8FCDA2240402; Fri, 1 Mar 2013 18:16:17 +0100 (CET) Message-ID: <5130E260.70300@deployingradius.com> Date: Fri, 01 Mar 2013 12:16:16 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <511AABCF.8020807@deployingradius.com> <512E306F.7060205@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "emu@ietf.org" Subject: Re: [Emu] Last call on 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, 01 Mar 2013 17:16:22 -0000 Sam Hartman wrote: > Uh, hello? I raised some comments in a message dated Feburary 23 with > subject "Comments on draft-ietf-emu-eap-tunnel-method," , a few of which > I consider substantive and would appreciate a response to those > comments. OK. I seem to have missed that, and a post from Jim Schaad. I'll respond with detailed updates in another message. Alan DeKok. From jsalowey@cisco.com Mon Mar 4 15:10:43 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 1470E21F8689 for ; Mon, 4 Mar 2013 15:10:43 -0800 (PST) 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 1Sbu4JAcDgJh for ; Mon, 4 Mar 2013 15:10:42 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5069721F8667 for ; Mon, 4 Mar 2013 15:10:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2141; q=dns/txt; s=iport; t=1362438642; x=1363648242; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=313Rcust0Bgml7LpPhJfYXs4hL6UPYdCEfAZdIsQ4qI=; b=HUnPIZL8s9kKnY7IsxBAH1hFYeWubiX/ISyu1RaHriSAaXYXwPJcYcvG RwvrqqGSEY8p/LgQOlKRiD38a8yk1VYVagHPixg2Hms0XvbJnliYsmpvQ H42RPSnLCo8cjxXHDPzSpK/BoY+cCvZRpt4HUN13BISiEZPtLSNh0W1J8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANEoNVGtJV2b/2dsb2JhbABEDsJGgQsWc4IfAQEBAwEBAQEkEzQLBQsCAQgiFBAnCyUCBA4FCIgFBgzAUQSOWQIxB2OBfGEDpzKCSTINgic X-IronPort-AV: E=Sophos;i="4.84,783,1355097600"; d="scan'208";a="183685795" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 04 Mar 2013 23:10:42 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r24NAf56007657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Mar 2013 23:10:41 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 17:10:41 -0600 From: "Joseph Salowey (jsalowey)" To: Sam Hartman Thread-Topic: [Emu] Comments on draft-ietf-emu-eap-tunnel-method Thread-Index: AQHOFo+int/mrrMJiUyR+rh3xIl+8piWknCA Date: Mon, 4 Mar 2013 23:10:41 +0000 Message-ID: References: <029201ce1565$32d03870$9870a950$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.140] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [Emu] Comments on 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, 04 Mar 2013 23:10:43 -0000 On Mar 1, 2013, at 7:15 AM, Sam Hartman wrote: >>>>>> "Jim" =3D=3D Jim Schaad writes: >>> There doesn't seem to be a way for a server to request channel >>> binding. If that's true we should probably add the following: >>> Since a server cannot indicate a desire for channel binding, >>> clients that > Jim> have >>> channel binding data to send SHOULD include channel-binding TLV >>> in a request-action TLV if mutual authentication (section 3.11) >>> succeeded. >=20 > Jim> If this is true - then I agree it is a flaw. >=20 > Jim> I think that one could send a channel-binding TLV with no data > Jim> to request that a client send channel binding data back. This > Jim> should not cause any significant problems. >=20 > If that's permitted then it should be explicitly documented. >=20 > I think that if this is permitted, everyone who implements channel > binding needs to be required to support this. >=20 > Jim> One could then have Channel-binding server->peer - no data > Jim> Channel-binding peer->server - here is my data Channel-binding > Jim> server->peer - here is my data >=20 > Again, let's document this if it is permitted. > It's clear the spec is unclear if you and I read if differently. >=20 [Joe] THis is a reasonable request. We'll need to make sure there is no am= biguity in the use of the empty message. Should this be covered in RFC 66= 77?=20 > Jim> However I believe that the client can initiate this by just > Jim> sending the channel binding TLV in the clear and not in a > Jim> request if the client wants to initiate it. >=20 > My reading is that you cannot send a channel binding outside of a > request. This needs clarification as well if we're reading it > differently. [Joe] I'm not sure what you are asking here. What is meant be sending the = CB TLV "in the clear and not in a request"? do you mean a request-action T= LV?=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Mon Mar 4 15:19:24 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 6DEEF21F866F for ; Mon, 4 Mar 2013 15:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 OSBWYP+UQDrf for ; Mon, 4 Mar 2013 15:19:23 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 46C4A21F8651 for ; Mon, 4 Mar 2013 15:19:14 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id DAEA720229; Mon, 4 Mar 2013 18:19:05 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 813494486; Mon, 4 Mar 2013 18:19:09 -0500 (EST) From: Sam Hartman To: "Joseph Salowey \(jsalowey\)" References: <029201ce1565$32d03870$9870a950$@augustcellars.com> Date: Mon, 04 Mar 2013 18:19:09 -0500 In-Reply-To: (Joseph Salowey's message of "Mon, 4 Mar 2013 23:10:41 +0000") 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: Sam Hartman , "" Subject: Re: [Emu] Comments on 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, 04 Mar 2013 23:19:24 -0000 >>>>> "Joseph" == Joseph Salowey (jsalowey) writes: [Joe] THis is a reasonable request. We'll need to make sure there is no ambiguity in the use of the empty message. Should this be covered in RFC 6677? RFC 6677 doesn't talk about how you decide you're going to do channel binding. I had mostly assumed you'd throw it in with some other message I guess, although once you consider crypto binding that gets more complex because you want CB after crypto binding some of the time. Note that I'm not requesting any specific behavior. I'm simply requesting that you document either that a server cannot request CB (must start with client) or document how a server requests cb. The message defined in RFC 6677 always has a code, so an empty message is clearly not a 6677 message. From ietf@augustcellars.com Mon Mar 4 18:00:29 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 7887911E80EE for ; Mon, 4 Mar 2013 18:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 odaMytB9CAzZ for ; Mon, 4 Mar 2013 18:00:29 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 15E3A11E80E8 for ; Mon, 4 Mar 2013 18:00:29 -0800 (PST) Received: from Philemon (dhcp63-140-207-211.hil-tpanohx.orl.wayport.net [63.140.207.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 0265838F0C; Mon, 4 Mar 2013 18:00:27 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" , "'Joseph Salowey \(jsalowey\)'" References: <029201ce1565$32d03870$9870a950$@augustcellars.com> In-Reply-To: Date: Mon, 4 Mar 2013 20:59:54 -0500 Message-ID: <009401ce1945$231d3e80$6957bb80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIuxCl7T2T4S0PLy9RRXTXiFJBVMQGCAO30Av8YRyUCWcvWdwEqc3cJl5TXAfA= Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Comments on 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: Tue, 05 Mar 2013 02:00:29 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Monday, March 04, 2013 6:19 PM > To: Joseph Salowey (jsalowey) > Cc: Sam Hartman; Jim Schaad; > Subject: Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method > > >>>>> "Joseph" == Joseph Salowey (jsalowey) > writes: > > [Joe] THis is a reasonable request. We'll need to make sure there is no > ambiguity in the use of the empty message. Should this be covered in RFC > 6677? > > RFC 6677 doesn't talk about how you decide you're going to do channel > binding. I had mostly assumed you'd throw it in with some other message I > guess, although once you consider crypto binding that gets more complex > because you want CB after crypto binding some of the time. > > Note that I'm not requesting any specific behavior. I'm simply requesting > that you document either that a server cannot request CB (must start with > client) or document how a server requests cb. > > The message defined in RFC 6677 always has a code, so an empty message is > clearly not a 6677 message. I agree - this is behavior that is described in this document and not in RFC 6677 - this is a how do you do it not a what is included type question. Jim From ietf@augustcellars.com Mon Mar 4 18:13:48 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 3046B21F87D3 for ; Mon, 4 Mar 2013 18:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 oNob5GsXffv8 for ; Mon, 4 Mar 2013 18:13:47 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2485D1F0D05 for ; Mon, 4 Mar 2013 18:13:40 -0800 (PST) Received: from Philemon (dhcp63-140-207-211.hil-tpanohx.orl.wayport.net [63.140.207.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id BF9B138E6A for ; Mon, 4 Mar 2013 18:13:39 -0800 (PST) From: "Jim Schaad" To: Date: Mon, 4 Mar 2013 21:13:06 -0500 Message-ID: <009c01ce1946$faad9c90$f008d5b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009D_01CE191D.11D8CD10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4ZRmnZwI77ejVITqqj5s72T9h97A== Content-Language: en-us Subject: [Emu] Comments on draft-ietf-emu-eap-tunnel-method-05 - Set #2 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, 05 Mar 2013 02:13:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009D_01CE191D.11D8CD10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have been doing my best not to send this message but it has finally slipped out. I keep wondering if we need to do something much more explicit in terms of both identifying and purposing the certificates that are being used for this method. Question #1 - Do we expect that the client certificates would only be used for this purpose and not for general purpose TLS client authentication? I would be shocked if this was not true for the server certificates. If so does this mean that we should define an EKU for the purpose of doing EAP Tunnel Method (allow it to be used for all of the previous and future versions thus being generic)? Question #2 - Do we want to try and solve the question Sam has raised about naming of entities in certificates. This would mean defining a new OtherName extension to PKIX for the purpose of placing NAIs into certificates. This would allow for an NAI of the form "@realm" to be placed in a server certificate to define that it is the EAP server for the realm. This does assume that there will not be two different servers which are disjoint servicing the same realm but that would be a very unusual case. Jim ------=_NextPart_000_009D_01CE191D.11D8CD10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have = been doing my best not to send this message but it has finally slipped = out.

 

I keep wondering if we need to do something much more = explicit in terms of both identifying and purposing the certificates = that are being used for this method.

 

Question #1 = – Do we expect that the client certificates would only be used for = this purpose and not for general purpose TLS client authentication? =  I would be shocked if this was not true for the server = certificates.  If so does this mean that we should define an EKU = for the purpose of doing EAP Tunnel Method (allow it to be used for all = of the previous and future versions thus being = generic)?

 

Question #2 – Do we want to try and solve the = question Sam has raised about naming of entities in certificates.  = This would mean defining a new OtherName extension to PKIX for the = purpose of placing NAIs into certificates.  This would allow for an = NAI of the form “@realm” to be placed in a server = certificate to define that it is the EAP server for the realm. =  This does assume that there will not be two different servers = which are disjoint servicing the same realm but that would be a very = unusual case.

 

Jim

 

------=_NextPart_000_009D_01CE191D.11D8CD10-- From jsalowey@cisco.com Tue Mar 5 10:38: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 E9B7D11E80F5 for ; Tue, 5 Mar 2013 10:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.599 X-Spam-Level: X-Spam-Status: No, score=-112.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 mkVA+h4nEFpT for ; Tue, 5 Mar 2013 10:38:07 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA3211E80AD for ; Tue, 5 Mar 2013 10:38:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4614; q=dns/txt; s=iport; t=1362508687; x=1363718287; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hY2HaSSGxaAWgBXft4pK6srMrIgMv8rroXRA29L+VrY=; b=gyHrqhd1mEfn+uPxj2iTANDuipbgrR/JdtwViKB1gqMlGY73sdtTVoey lYFHp8+n1nnjZSOZvlVxkYBbMj9VEbdE2OQB1W+4opN0Sqa/oTmSmR2Gs SLCQfeEn4TcMDwEDLguKUQ/+lFB0XDRHHer6v70TaTS1BgtFWPVGOzaNu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAL86NlGtJXG+/2dsb2JhbABFxHSBbhZzgisBAQEDATo/BQsCAQgOFBQQMiUBAQQOBQiIBQasSJAJjloCMQeCX2EDkwaUMoMIgic X-IronPort-AV: E=Sophos;i="4.84,788,1355097600"; d="scan'208";a="181049553" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 05 Mar 2013 18:38:06 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r25Ic6Dm005299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Mar 2013 18:38:06 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 12:38:06 -0600 From: "Joseph Salowey (jsalowey)" To: Jim Schaad Thread-Topic: Last call comments on emu-eap-tunnel-method-05 Thread-Index: Ac4Qd7MLsLiMgOSbQGyl8oqyFZWyiwJiyxQA Date: Tue, 5 Mar 2013 18:38:05 +0000 Message-ID: References: <026401ce1077$cffba050$6ff2e0f0$@augustcellars.com> In-Reply-To: <026401ce1077$cffba050$6ff2e0f0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.140] Content-Type: text/plain; charset="us-ascii" Content-ID: <786A638EA0A67B439EDD186507B7513F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "emu@ietf.org" Subject: Re: [Emu] Last call comments on emu-eap-tunnel-method-05 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, 05 Mar 2013 18:38:08 -0000 On Feb 21, 2013, at 1:10 PM, Jim Schaad wrote: > I have no comments that I would consider to be blocking. There are coupl= e > of issues that should be considered to be dealt with in the last call. >=20 > Jim >=20 >=20 >=20 > 1. Lower case must/may in the document. There are disputes about the ro= le > of a lower case must in a document. Some people consider it to be an RFC > 2119 usage and some people don't. If it is then these all need to be loo= ked > at, if it doesn't then I would suggest putting in text as part of the > RFC2119 boiler plate to say that lower case versions of these words have > their natural language meaning. >=20 [Joe] Thanks, well look at this and try to make the usage consistent with= 2119 and move other usages to different words > 2. I am not completely clear on this, but don't know if it needs to be > clarified. > Server and client rune one inner EAP method. > Server sends Crypto-Binding TLV and Result TLV > Client sends Crypto-Binding TLV, Request-Action TLV [Negotiate EAP] > Server sends EAP-Payload [EAP start method] > Does the server also needs to send an Intermediate-Result TLV per section > 3.3.1? > ---- Note - in section 3.3.3 - it would appear that there is a "may" > recommendation that the server actually send > Crypt-Binding TLV, Intermediate-Result TLV, Result TLV thus making the > problem not a problem. However this is not required behavior. >=20 [Joe] This needs to be clarified. Even if there is only one inner method t= he server needs to send and intermediate result TLV. How about OLD (section 3.3) It MUST be included with the Intermediate-Result TLV to perform Cryptographic Binding after each successful EAP method in a sequence of EAP methods, before proceeding with another inner EAP method. NEW The Crypto-Binding TLV and Intermediate-Result TLV MUST be included=20 to perform Cryptographic Binding after each successful EAP method in a sequence of one or more EAP methods. =20 > 3. Not completely sure the second to last paragraph in 3.3 is correct. > Should the server return the EAP success or failure based on the peer's > result TLV or the peer's request-action tlv? I think that either could b= e a > correct answer I just want to verify that the text presented is correct. >=20 [Joe] Good catch: OLD If the server ignores the request, it proceeds with termination of the tunnel and send the clear text EAP Success or Failure message based on the value of the peer's result TLV. NEW If the server ignores the request, it proceeds with termination of the tunnel and send the clear text EAP Success or Failure message based on the status field of t= he peer's request-action TLV. > 4. Last chance to change our minds and allocate an extra flag in section > 4.2.1 just in case we needed it. I have no idea which is going to be the > more scarce resource. But only one reserve flag might be an issue. >=20 [Joe] I think it would be preferable to keep the current format that is us= ed by other methods.=20 > 5. It is technically incorrect to say that the TLV Type is two octets > (section 4.2.2). I don't know that there is any reason to correct this a= s > it is essentially correct. Just a we need to be sure we don't want to fi= x > it. (Note: text is different in section 4.2.2) >=20 [Joe] OK > 6. section 4.2.13 - I think that the received version number is supposed= to > say "set to the TEAP version number received" not the "EAP version number= " >=20 [Joe] Correct > 7. section 4.3 s/multiple multiple Basic/multiple Basic/ >=20 [Joe] OK=20 > 8. Section 5.2 There are two possible confusions that could result in t= he > computation of the text string for the IMSK > a) It is possible that the string "\0" could be misinterpreted. This > could be stated as 0x00. > b) It is possible that the 64 could be misinterpreted as being longer > than a byte and thus could be stated as 0x40. (Oops just looked at the > referenced document and it is 0x00 0x40). > Not clear if this really needs to be changed. >=20 [Joe] We could add the note from 5295=20 where: | denotes concatenation "EMSK" consists of the 4 ASCII values for the letters "\0" =3D is a NULL octet (0x00 in hex) length is the 2-octet unsigned integer 8 in network byte order > 9. Section 5.2 - s/thendoesn/?????/ >=20 >=20 [Joe] s/thendoesn/then >=20 >=20 >=20 >=20 >=20 From jsalowey@cisco.com Tue Mar 5 10:43:16 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 1355F11E80F5 for ; Tue, 5 Mar 2013 10:43:16 -0800 (PST) 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 dQlnfIACai6O for ; Tue, 5 Mar 2013 10:43:15 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFEB11E8110 for ; Tue, 5 Mar 2013 10:43:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7317; q=dns/txt; s=iport; t=1362508994; x=1363718594; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OPSrTths2LhYHUkySrs8uUX5a3S0coFU0zkz2Eo0NY4=; b=X80k32ONHTDsJ9tJV09k8/KM7T2dtxYeHHd7q/TTPi29N75IARTMjf7b CqWurr0kPRm1+KX3kw+XMgGEtTJ7G/Cl9GJYD0Vh/OaGnLAOk5AMqijOZ Rq14o6W5fMnKvuyepp+tViBak49TtBM42OSqcb18WaxBTj5TM3R0MNvzB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAF07NlGtJV2c/2dsb2JhbAA8CQ7EZoFuFnOCKwEBAQMBAQEBNzQLBQsCAQgiFBAnCyUCBA4FCIgFBgysQZAEBI1TgQcCMQeCX2EDpziCST+BayQY X-IronPort-AV: E=Sophos;i="4.84,788,1355097600"; d="scan'208";a="184041673" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 05 Mar 2013 18:43:14 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r25IhDim009610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Mar 2013 18:43:13 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 12:43:13 -0600 From: "Joseph Salowey (jsalowey)" To: Sam Hartman Thread-Topic: [Emu] Comments on draft-ietf-emu-eap-tunnel-method Thread-Index: AQHOGdFKnt/mrrMJiUyR+rh3xIl+8g== Date: Tue, 5 Mar 2013 18:43:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.140] Content-Type: text/plain; charset="us-ascii" Content-ID: <271AC5F75AEF2C43A38974B3A3B12A05@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [Emu] Comments on 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: Tue, 05 Mar 2013 18:43:16 -0000 On Feb 23, 2013, at 5:46 PM, Sam Hartman wrote: >=20 >=20 > First, the document has been improved a lot in its clarity since the > last time I read it. I'd really like to thank the editors, Jim and > everyone else who gave comments for some excellent work. >=20 >=20 > TEAP is by far the best EAP method I've ever reviewed, and I think > security of EAP conversations would be significantly improved if people > implement and deploy TEAP. >=20 > Section 3.4: >=20 > Does the server_id depend on whether the identifier is actually > authenticated? > That is, let's say the server is using a certificate but the client has > no way to validate the certificate back to a trust anchor. > However, the client uses some strong inner method and EMSK-based crypto > binding to verify the server. > Does the subject from the server cert make its way into the server ID > in this case? >=20 [Joe] Section 3.4 says all authenticated identities so in this case I wou= ld not expect it to make its way into the server ID. > Is it important that implementations get binary identical strings for > server_id on both sides of the conversation? [Joe] I don't think the server_id is used in the protocol or on the wire, = so its encoding is a local matter. I don't think both sides need to have = binary identical strings. =20 > I think the text in 3.4 is sufficient that you'd get the right security > properties out of the identity, but I suspect different implementations > could get slightly different encoding etc. > I have never used peer id, server id or session id, so I'm not sure if > anyone cares about that. > 3.5: >=20 > old: > tls_unique =3D tls_unique for the phase 1 outer tunnel as defined by > [RFC5929]. >=20 > new: > tls_unique =3D tls_unique for the phase 1 outer tunnel at the > beginning of phase 2 as defined by > section 3.1 of [RFC5929]. >=20 >=20 > rationale: The quantity described in section 3.1 of rfc 5929 can change > when there is TLS renegotiation. > This should avoid that. [Joe] Looks good. To be clear if there is re-negotiation then the re-nego= tiated TLS unique will be used. =20 > Section 3.8-3.10: > All of these sections involve peer services in the terms of > draft-ietf-abfabf-emu-crypto-bind. > I believe the advice in section 4.2 of draft-ietf-emu-crypto-bind > applies quite strongly here. > In particular, the peer MUST track whether it has authenticated the > server. >=20 > There's text repeated at various points in the TEAP spec that tries to > say this, including some text in 3.8 and a hint at 3.10. >=20 > I think this needs to be more unified. > In particular I propose that: >=20 > * A new section 3.11 titled "Mutual Authentication for Peer Services" be > added: >=20 >=20 > Several TEAP services including server unauthenticated provisioning, > PAC provisioning, certificate provisioning and channel binding depend > on the peer trusting the TEAP server. Peers need to mutually > authenticate the server before these peer services are used. >=20 > TEAP peers MUST track whether mutual authentication has taken > place. 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 andconfirming the entity > named by the certificate is the intended server. 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. Alternatively, if an inner EAP method providing mutual > authentication and an Extended Master Session Key (EMSK) is executed > and cryptographic binding with the EMSK compound MAC present (section > 4.2.13), then the session is mutually authenticated and peer services > can be used. TEAP implementations SHOULD Not use peer services by > default unless the session is mutually authenticated. TEAP > implementations SHOULD have a configuration where authentication fails > if mutual authentication cannot be achieved. >=20 > An additional complication arises when a > tunnel method authenticates multiple parties such as authenticating > both the peer machine and the peer user to the EAP server. Depending > on how mutual authentication is achieved, only some of these parties > may have confidence in it. For example if a strong shared secret is > used to mutually authenticate the user and the EAP server, the machine > may not have confidence that the EAP server is the authenticated party > if the machine cannot trust the user not to disclose the shared secret > to an attacker. In these cases, the parties who have achieved mutual > authentication need to be considered when evaluating whether to use > peer services. >=20 >=20 > * Section 3.8-3.10 explicitly refer to this new section. Some of the > text about server authentication already present in these sections can > be removed. >=20 > * The channel binding TLV and the request-action TLV should also refer > to 3.11. >=20 [Joe] This is a good suggestion. I'm not sure how exactly to incorporate t= he text into the document at this point. Maybe we should have a section "3= .8 Peer Services" which has this text and have the original 3.8-3.10 as sub= sections. =20 > Section 4.2.7: >=20 > Replace the definition of data with >=20 > The data field contains a channel-binding message as defined in section > 5.3 of RFC 6677. >=20 > Will the channel binding data (client to server) ever be outside of a > request-action TLV? > If not, it's probably worth pointing this out. >=20 > There doesn't seem to be a way for a server to request channel binding. > If that's true we should probably add the following: > Since a server cannot indicate a desire for channel binding, clients > that have channel binding data to send SHOULD include channel-binding > TLV in a request-action TLV if mutual authentication (section 3.11) > succeeded. >=20 [Joe] We should have a section that explicitly discusses channel binding a= s section 3.x. We should include a mechanism for the server to initiate b= indings.=20 > section 7.3: > Please update references to draft-hartman-emu-mulutal-crypto-bind to > draft-ietf-emu-mutual-crypto-bind >=20 >=20 [Joe] OK > section 7.6: >=20 > Replace peer MUST validate with peer SHOULD validate. 3.10 is an > example where the peer SHOULDN't validate, and no one is going to make > that a MUST so let's not lie. I'd also like to see the requirement for > implementations to support matching the realm of a NAI against a dns > name in the subjectAltName to be a MUST not a SHOULD. I think we have > strong evidence that we need an interoperable way to name EAP servers. > Note that's MUST implement, not MUSt use. >=20 [Joe] Looks OK, we probably should indicate when the its OK not to do th= e validation and what the consequences are for not doing the validation. Jim's recent message may add to the certificate validation piece. =20 > --Sam > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From jsalowey@cisco.com Tue Mar 5 10:43:17 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 AA41911E8124 for ; Tue, 5 Mar 2013 10:43:17 -0800 (PST) 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 qifftjZA0jV2 for ; Tue, 5 Mar 2013 10:43:16 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 993DE11E8110 for ; Tue, 5 Mar 2013 10:43:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8828; q=dns/txt; s=iport; t=1362508996; x=1363718596; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HrEW6+NV1iMbCcRXX1Y7Rihb/VYe/irREwO1OtwJkEI=; b=YDk7rsbQ0JycOW+skn3o7W15ZCb5PgB7vVxVvqBS5wsw9FxT2Mnw+rNw wNIVT28J1lkWTill3AeXLHFoc3vpcwJwqyutonGw9WAezEsgMr9/eq6Uz ara4/VNjqzQp9FU0ew2LWB5XOsWRxf6iSou+RWyDBYWdSwrnmvzWsd3EB Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANQ7NlGtJV2b/2dsb2JhbAA8CcR0gW4Wc4IrAQEBAwEBAQEkEzQLBQcEAgEIDgMEAQELFAkHJwsUCQgCBA4FCIgFBgysQ5AEBI1TgQcCJgsHBoJZYQOnOIMIgWskGA X-IronPort-AV: E=Sophos;i="4.84,788,1355097600"; d="scan'208";a="181051461" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 05 Mar 2013 18:43:16 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r25IhFPV032491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Mar 2013 18:43:15 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 12:43:15 -0600 From: "Joseph Salowey (jsalowey)" To: Jim Schaad Thread-Topic: [Emu] Comments on draft-ietf-emu-eap-tunnel-method Thread-Index: AQHOGdFLnt/mrrMJiUyR+rh3xIl+8g== Date: Tue, 5 Mar 2013 18:43:15 +0000 Message-ID: References: <029201ce1565$32d03870$9870a950$@augustcellars.com> In-Reply-To: <029201ce1565$32d03870$9870a950$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.140] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Sam Hartman , "" Subject: Re: [Emu] Comments on 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: Tue, 05 Mar 2013 18:43:17 -0000 On Feb 27, 2013, at 7:39 PM, Jim Schaad wrote: > Sam, >=20 > My responses are inline. May not agree with the authors however. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of >> Sam Hartman >> Sent: Saturday, February 23, 2013 5:47 PM >> To: emu@ietf.org >> Subject: [Emu] Comments on draft-ietf-emu-eap-tunnel-method >>=20 >>=20 >>=20 >> First, the document has been improved a lot in its clarity since the las= t > time I >> read it. I'd really like to thank the editors, Jim and everyone else who > gave >> comments for some excellent work. >>=20 >>=20 >> TEAP is by far the best EAP method I've ever reviewed, and I think > security of >> EAP conversations would be significantly improved if people implement an= d >> deploy TEAP. >>=20 >> Section 3.4: >>=20 >> Does the server_id depend on whether the identifier is actually >> authenticated? >> That is, let's say the server is using a certificate but the client has = no > way to >> validate the certificate back to a trust anchor. >> However, the client uses some strong inner method and EMSK-based crypto >> binding to verify the server. >> Does the subject from the server cert make its way into the server ID i= n > this >> case? >>=20 >> Is it important that implementations get binary identical strings for > server_id >> on both sides of the conversation? >> I think the text in 3.4 is sufficient that you'd get the right security > properties >> out of the identity, but I suspect different implementations could get > slightly >> different encoding etc. >> I have never used peer id, server id or session id, so I'm not sure if > anyone >> cares about that. >=20 > I would expect that the id from the certificate would be returned if the > inner method provided mutual authentication and the crypto bindings were > successful. At that point one would have a statement about the certifica= te > that says it matches that of any server id stated inside of the tunnel. = The > certificate would be the one presented by the certificate - could not cha= nge > without TLS failing. The channel binding would give you validation of th= e > tunnel and mutual auth would give you validation of the server. >=20 [Joe] My inclination is to not export the certificate ID in this case. If = it is the same as a inner method ID then it will already be exported. If i= ts different its not clear that the name in the certificate should be used = for any purpose. I think it would be OK to store the certificate or its a= ssociated public key to validate future connections. =20 > I don't know what it would be to have binary identical strings on both > sides. Only the peer side would get server ids and only the server side > would get peer ids. =20 >=20 > As with you I have never used the ids - so I would not know what they are > used for in general either. >=20 >> 3.5: >>=20 >> old: >> tls_unique =3D tls_unique for the phase 1 outer tunnel as defined b= y >> [RFC5929]. >>=20 >> new: >> tls_unique =3D tls_unique for the phase 1 outer tunnel at the >> beginning of phase 2 as defined by section 3.1 of [RFC5929]. >>=20 >>=20 >> rationale: The quantity described in section 3.1 of rfc 5929 can change > when >> there is TLS renegotiation. >> This should avoid that. >> Section 3.8-3.10: >=20 > This is a reasonable change. >=20 >> All of these sections involve peer services in the terms of > draft-ietf-abfabf- >> emu-crypto-bind. >> I believe the advice in section 4.2 of draft-ietf-emu-crypto-bind appli= es > quite >> strongly here. >> In particular, the peer MUST track whether it has authenticated the > server. >>=20 >> There's text repeated at various points in the TEAP spec that tries to s= ay > this, >> including some text in 3.8 and a hint at 3.10. >>=20 >> I think this needs to be more unified. >> In particular I propose that: >>=20 >> * A new section 3.11 titled "Mutual Authentication for Peer Services" be >> added: >>=20 >>=20 >> Several TEAP services including server unauthenticated provisioning, PAC >> provisioning, certificate provisioning and channel binding depend on the > peer >> trusting the TEAP server. Peers need to mutually authenticate the serve= r >> before these peer services are used. >>=20 >> TEAP peers MUST track whether mutual authentication has taken place. >> Mutual authentication results if the peer trusts the provided server >> certificate belongs to the server; typically this involves both validati= ng > the >> certificate to a trust anchor andconfirming the entity named by the > certificate >> is the intended server. Mutual authentication also results when the >> procedures of section 3.3 are used to resume a session in which the serv= er >> was previously mutually authenticated. Alternatively, if an inner EAP > method >> providing mutual authentication and an Extended Master Session Key >> (EMSK) is executed and cryptographic binding with the EMSK compound >> MAC present (section 4.2.13), then the session is mutually authenticated > and >> peer services can be used. TEAP implementations SHOULD Not use peer >> services by default unless the session is mutually authenticated. TEAP >> implementations SHOULD have a configuration where authentication fails i= f >> mutual authentication cannot be achieved. >>=20 >> An additional complication arises when a tunnel method authenticates >> multiple parties such as authenticating both the peer machine and the pe= er >> user to the EAP server. Depending on how mutual authentication is >> achieved, only some of these parties may have confidence in it. For > example >> if a strong shared secret is used to mutually authenticate the user and > the >> EAP server, the machine may not have confidence that the EAP server is t= he >> authenticated party if the machine cannot trust the user not to disclose > the >> shared secret to an attacker. In these cases, the parties who have > achieved >> mutual authentication need to be considered when evaluating whether to >> use peer services. >>=20 >>=20 >> * Section 3.8-3.10 explicitly refer to this new section. Some of the >> text about server authentication already present in these sections can >> be removed. >>=20 >> * The channel binding TLV and the request-action TLV should also refer >> to 3.11. >>=20 >> Section 4.2.7: >>=20 >> Replace the definition of data with >>=20 >> The data field contains a channel-binding message as defined in section >> 5.3 of RFC 6677. >>=20 >> Will the channel binding data (client to server) ever be outside of a > request- >> action TLV? >> If not, it's probably worth pointing this out. >>=20 >> There doesn't seem to be a way for a server to request channel binding. >> If that's true we should probably add the following: >> Since a server cannot indicate a desire for channel binding, clients tha= t > have >> channel binding data to send SHOULD include channel-binding TLV in a >> request-action TLV if mutual authentication (section 3.11) succeeded. >=20 > If this is true - then I agree it is a flaw. =20 >=20 > I think that one could send a channel-binding TLV with no data to request > that a client send channel binding data back. This should not cause any > significant problems. >=20 > One could then have > Channel-binding server->peer - no data > Channel-binding peer->server - here is my data > Channel-binding server->peer - here is my data >=20 > However I believe that the client can initiate this by just sending the > channel binding TLV in the clear and not in a request if the client wants= to > initiate it. >=20 >>=20 >> section 7.3: >> Please update references to draft-hartman-emu-mulutal-crypto-bind to >> draft-ietf-emu-mutual-crypto-bind >>=20 >>=20 >> section 7.6: >>=20 >> Replace peer MUST validate with peer SHOULD validate. 3.10 is an exampl= e >> where the peer SHOULDN't validate, and no one is going to make that a >> MUST so let's not lie. I'd also like to see the requirement for >> implementations to support matching the realm of a NAI against a dns nam= e >> in the subjectAltName to be a MUST not a SHOULD. I think we have strong >> evidence that we need an interoperable way to name EAP servers. >> Note that's MUST implement, not MUSt use. >>=20 >> --Sam >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Tue Mar 5 11:34: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 A135521F8533 for ; Tue, 5 Mar 2013 11:34:05 -0800 (PST) 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 CxV3GJm6VhYK for ; Tue, 5 Mar 2013 11:34:05 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAAE21F852B for ; Tue, 5 Mar 2013 11:34:03 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 886C52003E; Tue, 5 Mar 2013 14:33:56 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DC7754497; Tue, 5 Mar 2013 14:34:02 -0500 (EST) From: Sam Hartman To: "Joseph Salowey \(jsalowey\)" References: Date: Tue, 05 Mar 2013 14:34:02 -0500 In-Reply-To: (Joseph Salowey's message of "Tue, 5 Mar 2013 18:43:12 +0000") 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: Sam Hartman , "" Subject: Re: [Emu] Comments on 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: Tue, 05 Mar 2013 19:34:05 -0000 OK. Based on your description of how peer and server ID are used, I have no concerns about 3.4. From aland@deployingradius.com Sun Mar 10 12:12:48 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 A2F9B21F86A8 for ; Sun, 10 Mar 2013 12:12:48 -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 mX8cemFn3EQi for ; Sun, 10 Mar 2013 12:12:48 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id C956721F859C for ; Sun, 10 Mar 2013 12:12:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id BC13722410D0 for ; Sun, 10 Mar 2013 20:12:45 +0100 (CET) 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 7jiXlZajFheY for ; Sun, 10 Mar 2013 20:12:45 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121452.dsl.bell.ca [70.26.48.108]) by power.freeradius.org (Postfix) with ESMTPSA id CE2B82240CF5 for ; Sun, 10 Mar 2013 20:12:44 +0100 (CET) Message-ID: <513CDB2B.60605@deployingradius.com> Date: Sun, 10 Mar 2013 15:12:43 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "emu@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Emu] Slides 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, 10 Mar 2013 19:12:48 -0000 Can the presenters please send slides to the chairs? Thanks. From jsalowey@cisco.com Mon Mar 11 08:31:14 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 73FC521F8B84 for ; Mon, 11 Mar 2013 08:31:14 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 aUUZfP1lPfrS for ; Mon, 11 Mar 2013 08:31:13 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5C62C21F8B81 for ; Mon, 11 Mar 2013 08:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8713; q=dns/txt; s=iport; t=1363015873; x=1364225473; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=txi4aaR5dkBUgOVZy7AE1Hk6yanPB+0w7e+AMIOJd/k=; b=M4cOkLdG1ijTg+tgZEFgdvGuUvYJYgYRNUTWEVUvYjwEuAv77C5sW2ho Egidh92DM/oHBEfzLOIpOzcVtbJoVhj7w+MHSncfQF9AiBuozntv0LyhX fi89URpe2U5sp8RSewmFTabiIftHiZWEZ0bcU1wk/ewlUy8pXFEK6037o Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOb3PVGtJV2c/2dsb2JhbAA5BAaEFcA+gVkWdIIqAQEEAQEBawsQAgEIDhQdBycLFBEBAQQOAwIIiAsMvAYTBI1TFnQtBAeCX2EDp0qDCkCBKgc3 X-IronPort-AV: E=Sophos;i="4.84,824,1355097600"; d="scan'208,217";a="183139070" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 11 Mar 2013 15:31:06 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2BFV60F010077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 15:31:06 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 10:31:06 -0500 From: "Joseph Salowey (jsalowey)" To: Jim Schaad Thread-Topic: [Emu] Comments on draft-ietf-emu-eap-tunnel-method-05 - Set #2 Thread-Index: Ac4ZRmnZwI77ejVITqqj5s72T9h97AFUPDOA Date: Mon, 11 Mar 2013 15:31:05 +0000 Message-ID: References: <009c01ce1946$faad9c90$f008d5b0$@augustcellars.com> In-Reply-To: <009c01ce1946$faad9c90$f008d5b0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.223.19] Content-Type: multipart/alternative; boundary="_000_A95B4818FD85874D8F16607F1AC7C628A88CA3xmbrcdx09ciscocom_" MIME-Version: 1.0 Cc: "" Subject: Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method-05 - Set #2 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, 11 Mar 2013 15:31:14 -0000 --_000_A95B4818FD85874D8F16607F1AC7C628A88CA3xmbrcdx09ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable HI Jim, Thanks for bringing this up. I think it might be better to address this i= n a separate document since I think it can have more general applicability = than TEAP. I'll add this to the TEAP discussion in Orlando. Comments inl= ine below: On Mar 4, 2013, at 6:13 PM, Jim Schaad > wrote: I have been doing my best not to send this message but it has finally slipp= ed out. I keep wondering if we need to do something much more explicit in terms of = both identifying and purposing the certificates that are being used for thi= s method. Question #1 =96 Do we expect that the client certificates would only be use= d for this purpose and not for general purpose TLS client authentication? = I would be shocked if this was not true for the server certificates. If so= does this mean that we should define an EKU for the purpose of doing EAP T= unnel Method (allow it to be used for all of the previous and future versio= ns thus being generic)? [Joe] Both cases exist in deployments today, there are cases where server a= nd client certificates are used for both HTTPS and EAP. It is more common = on the client side. I believe EAP-TLS specifies the same EKUs as TLS for H= TTP. I've always found it a bit strange, but I don't think ti has present= ed a serious deployment issue. I think it would be reasonable to define a= new EKU, but I'd like to understand how it would or wouldn't work with wha= t is out there. Question #2 =96 Do we want to try and solve the question Sam has raised abo= ut naming of entities in certificates. This would mean defining a new Othe= rName extension to PKIX for the purpose of placing NAIs into certificates. = This would allow for an NAI of the form =93@realm=94 to be placed in a ser= ver certificate to define that it is the EAP server for the realm. This do= es assume that there will not be two different servers which are disjoint s= ervicing the same realm but that would be a very unusual case. [Joe] Being able to identify the realm and NAI would be good. For the real= m does this need to be distinct from DNS name? Jim _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu --_000_A95B4818FD85874D8F16607F1AC7C628A88CA3xmbrcdx09ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0E3E747946451B4280ACA17006BF26D0@cisco.com> Content-Transfer-Encoding: quoted-printable HI Jim,

Thanks for bringing this up.   I think it might be better to addr= ess this in a separate document since I think it can have more general appl= icability than TEAP.   I'll add this to the TEAP discussion in Orlando= .  Comments inline below:
On Mar 4, 2013, at 6:13 PM, Jim Schaad <ietf@augustcellars.com> wrote:

I have been doing my best not to send this message but it has finally slipp= ed out.
 
I keep wondering if we need to do something much more explicit in terms of = both identifying and purposing the certificates that are being used for thi= s method.
 
Question #1 =96 Do we expect that the client certificates would only be use= d for this purpose and not for general purpose TLS client authentication? &= nbsp;I would be shocked if this was not true for the server certificates.&n= bsp; If so does this mean that we should define an EKU for the purpose of doing EAP Tunnel Method (allow it to be used for= all of the previous and future versions thus being generic)?
 

[Joe] Both cases exist in deployments today, there are cases where ser= ver and client certificates are used for both HTTPS and EAP.  It is mo= re common on the client side.  I believe EAP-TLS specifies the same EK= Us as TLS for HTTP.   I've always found it a bit strange, but I don't think ti has presented a serious deployment iss= ue.   I think it would be reasonable to define a new EKU, but I'd like= to understand how it would or wouldn't work with what is out there. <= /div>



Question #2 =96 Do we want to try and solve the question Sam has raised abo= ut naming of entities in certificates.  This would mean defining a new= OtherName extension to PKIX for the purpose of placing NAIs into certifica= tes.  This would allow for an NAI of the form =93@realm=94 to be placed in a server certificate to define that it i= s the EAP server for the realm.  This does assume that there will not = be two different servers which are disjoint servicing the same realm but th= at would be a very unusual case.
 
[Joe] Being able to identify the realm and NAI would be good.  Fo= r the realm does this need to be distinct from DNS name? 


Jim
 
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu<= /a>

--_000_A95B4818FD85874D8F16607F1AC7C628A88CA3xmbrcdx09ciscocom_-- From internet-drafts@ietf.org Thu Mar 14 08:05:46 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 3AB7911E825C; Thu, 14 Mar 2013 08:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.011 X-Spam-Level: X-Spam-Status: No, score=-101.011 tagged_above=-999 required=5 tests=[AWL=1.589, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 OjGs41HCcFvh; Thu, 14 Mar 2013 08:05:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF7611E8249; Thu, 14 Mar 2013 08:05:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130314150526.32431.90635.idtracker@ietfa.amsl.com> Date: Thu, 14 Mar 2013 08:05:26 -0700 Cc: emu@ietf.org Subject: [Emu] I-D Action: 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: Thu, 14 Mar 2013 15:05:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of the IE= TF. Title : EAP Mutual Cryptographic Binding Author(s) : Sam Hartman Margaret Wasserman Dacheng Zhang Filename : draft-ietf-emu-crypto-bind-03.txt Pages : 25 Date : 2013-03-14 Abstract: As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. [RFC 3748] is a facility that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in- the-middle attacks and recommends mutual cryptographic binding, a new form of cryptographic binding that protects both peer and server along with other mitigations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-emu-crypto-bind-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-crypto-bind-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jsalowey@cisco.com Mon Mar 18 10:03:07 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 1237521F85ED for ; Mon, 18 Mar 2013 10:03:07 -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 JDBViAZT8BdR for ; Mon, 18 Mar 2013 10:02:59 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1A921F8634 for ; Mon, 18 Mar 2013 10:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=256; q=dns/txt; s=iport; t=1363626082; x=1364835682; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=zOY2aYGyvRk8rbJ1H8kWGfMuifZY5PR3enTzccHa+9A=; b=DmCmoERmvsygMa7sbT7WAaNrPooDxMrITFE9LE7WvFjdP2HW2Q9PyWYN c6Iqrg2MkGLSa1kfuepGamfQPaq98JqRy0l5/bIaytPa5EkSkPOpvQm0p QjK7IXSXo+nopjynBVr57KbdcMexpimuZW73UaF5ALahUOYYxmhI0/oZp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArULAPpGR1GtJV2b/2dsb2JhbABDh1qsMZETAgGBVhZ0giYBBB0dNB0BKhRCJwQbiAwMoRGgf45QFIMXYQOXfY9jgwqCKA X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="188707519" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 18 Mar 2013 17:01:21 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2IH1KN7026497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 18 Mar 2013 17:01:20 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 12:01:21 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Working Group Last Call for draft-ietf-emu-crypto-bind-03 Thread-Index: AQHOI/o2ZoCmk1ZuYEen1acLdkt7yw== Date: Mon, 18 Mar 2013 17:01:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.151] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Emu] Working Group Last Call for draft-ietf-emu-crypto-bind-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, 18 Mar 2013 17:03:07 -0000 This is an announcement for working group last call for draft-ietf-emu-cryp= to-bind-03. Please send your comments to the EMU mailing list by April 12,= 2013. The tools URL for the daft is: http://tools.ietf.org/html/draft-ietf-emu-crypto-bind-03 From internet-drafts@ietf.org Fri Mar 22 11:18:04 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 B43D521F9012; Fri, 22 Mar 2013 11:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 rxoGmL-V2IB4; Fri, 22 Mar 2013 11:18:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C8B21F8733; Fri, 22 Mar 2013 11:18:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130322181803.26751.78254.idtracker@ietfa.amsl.com> Date: Fri, 22 Mar 2013 11:18:03 -0700 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-eap-tunnel-method-06.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: Fri, 22 Mar 2013 18:18:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of the IE= TF. Title : Tunnel EAP Method (TEAP) Version 1 Author(s) : Hao Zhou Nancy Cam-Winget Joseph Salowey Stephen Hanna Filename : draft-ietf-emu-eap-tunnel-method-06.txt Pages : 105 Date : 2013-03-22 Abstract: This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-eap-tunnel-method-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/