From khoeper@motorola.com Wed Sep 1 07:30:26 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D315B3A693F for ; Wed, 1 Sep 2010 07:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zQ0tKuxmkjk for ; Wed, 1 Sep 2010 07:30:08 -0700 (PDT) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with ESMTP id 599543A694E for ; Wed, 1 Sep 2010 07:30:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-3.tower-153.messagelabs.com!1283351429!18385510!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.13] Received: (qmail 27071 invoked from network); 1 Sep 2010 14:30:29 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (136.182.1.13) by server-3.tower-153.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2010 14:30:29 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate3.mot.com (8.14.3/8.14.3) with ESMTP id o81EUTHM026514 for ; Wed, 1 Sep 2010 07:30:29 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o81EUT0G003332 for ; Wed, 1 Sep 2010 09:30:29 -0500 (CDT) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o81EUSSK003320 for ; Wed, 1 Sep 2010 09:30:28 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB49E2.2CC1B8E8" Date: Wed, 1 Sep 2010 10:30:06 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F08073B96@de01exm68.ds.mot.com> In-Reply-To: <000001cb497d$ca849fa0$5f8ddee0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] security paper on tunneled authentication Thread-Index: ActJI9JzT1n39f/hSk64b3toJWmCkQAWcQSAABj2r0A= References: <000001cb497d$ca849fa0$5f8ddee0$@net> From: "Hoeper Katrin-QWKN37" To: "Glen Zorn" , "Bernard Aboba" , X-CFilter-Loop: Reflected Subject: Re: [Emu] security paper on tunneled authentication X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 14:30:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB49E2.2CC1B8E8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I never said the document was broken, just that my paper would be a good reference to make implementers aware of the potential dangers of MITM attacks. =20 I will check the current draft for conflicts and, if necessary, propose changes. =20 Katrin =20 ________________________________ From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Glen Zorn Sent: Tuesday, August 31, 2010 9:31 PM To: 'Bernard Aboba'; emu@ietf.org Subject: Re: [Emu] security paper on tunneled authentication =20 I agree w/Bernard. It is never too late to fix a broken document. =20 Hope this helps. =20 ~gwz =20 From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, August 31, 2010 10:48 PM To: emu@ietf.org Subject: Re: [Emu] security paper on tunneled authentication =20 Katrina Hoeper said: "Unfortunately, it seems to be too late to reference the analysis in the tunnel requirement draft, but I hope that some people still might find it interesting." [BA] The paper represents the most comprehensive analysis of tunneled authentication security to date, and brings into question a number of assumptions that have been made as to how MITM in the middle attacks can be mitigated. In looking over the tunnel requirements document, there are only a few places where the issue of MITM attacks is discussed, so if you believe there are changes that need to be made, you should go ahead and propose them. =20 ------_=_NextPart_001_01CB49E2.2CC1B8E8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I never said the document was = broken, just that my paper would be a good reference to make implementers aware of = the potential dangers of MITM attacks.

 

I will check the current draft for conflicts and, if necessary, propose = changes.

 

Katrin

 


From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Glen Zorn
Sent: Tuesday, August 31, = 2010 9:31 PM
To: 'Bernard Aboba'; = emu@ietf.org
Subject: Re: [Emu] = security paper on tunneled authentication

 

I agree = w/Bernard.  It is never too late to fix a broken = document.

 

Hope this = helps.

 

 ~gwz

 <= /p>

From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Tuesday, August 31, = 2010 10:48 PM
To: emu@ietf.org
Subject: Re: [Emu] = security paper on tunneled authentication

 

Katrina Hoeper said:

"Unfortunately, it seems to be too late to reference the analysis in the tunnel = requirement draft, but I hope that some people still might find it = interesting."

[BA] The paper = represents the most comprehensive analysis of tunneled authentication security to = date, and brings into question a number of assumptions that have been made as = to how MITM in the middle attacks can be mitigated.     In = looking over the tunnel requirements document,  there are only a few places = where the issue of MITM attacks is discussed, so if you believe there are = changes that need to be made, you should go ahead and propose them. =  

------_=_NextPart_001_01CB49E2.2CC1B8E8-- From aland@deployingradius.com Wed Sep 1 07:33:39 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BF53A699E for ; Wed, 1 Sep 2010 07:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.851 X-Spam-Level: X-Spam-Status: No, score=-101.851 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPADZ6AZMwJa for ; Wed, 1 Sep 2010 07:33:38 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 6E3503A6812 for ; Wed, 1 Sep 2010 07:33:36 -0700 (PDT) Message-ID: <4C7E645D.9090504@deployingradius.com> Date: Wed, 01 Sep 2010 16:34:05 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Hoeper Katrin-QWKN37 References: <000001cb497d$ca849fa0$5f8ddee0$@net> <3A241A6B234BE948B8B474D261FEBC2F08073B96@de01exm68.ds.mot.com> In-Reply-To: <3A241A6B234BE948B8B474D261FEBC2F08073B96@de01exm68.ds.mot.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , emu@ietf.org Subject: Re: [Emu] security paper on tunneled authentication X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 14:33:39 -0000 Hoeper Katrin-QWKN37 wrote: > I will check the current draft for conflicts and, if necessary, propose > changes. I think that the main issue with the draft is that it requires tunneled methods to allow for password authentication. Your analysis paper says that password methods cannot be made resistant to these attacks. If that is right, then I don't think there is anything to do in the draft. Alan DeKok. From khoeper@motorola.com Wed Sep 1 07:40:32 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CBFA3A69A4 for ; Wed, 1 Sep 2010 07:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.109 X-Spam-Level: X-Spam-Status: No, score=-6.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44EYBd0d9jLt for ; Wed, 1 Sep 2010 07:40:26 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id AFDC23A6958 for ; Wed, 1 Sep 2010 07:40:09 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-11.tower-55.messagelabs.com!1283352038!42321093!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 28506 invoked from network); 1 Sep 2010 14:40:38 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-11.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Sep 2010 14:40:38 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate4.mot.com (8.14.3/8.14.3) with ESMTP id o81EecUS009990 for ; Wed, 1 Sep 2010 07:40:38 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o81EebeY015247 for ; Wed, 1 Sep 2010 09:40:38 -0500 (CDT) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o81EebcZ015229 for ; Wed, 1 Sep 2010 09:40:37 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Sep 2010 10:40:15 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F08073BB8@de01exm68.ds.mot.com> In-Reply-To: <4C7E645D.9090504@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] security paper on tunneled authentication Thread-Index: ActJ4r3YSx2m5lmmR96GxqMH4dfCiwAACeWg References: <000001cb497d$ca849fa0$5f8ddee0$@net> <3A241A6B234BE948B8B474D261FEBC2F08073B96@de01exm68.ds.mot.com> <4C7E645D.9090504@deployingradius.com> From: "Hoeper Katrin-QWKN37" To: "Alan DeKok" X-CFilter-Loop: Reflected Cc: Bernard Aboba , emu@ietf.org Subject: Re: [Emu] security paper on tunneled authentication X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 14:40:32 -0000 I agree. That's why I was thinking that adding a reference that makes implementers aware of this problem would be a good idea. Then they can make an educated decision about whether they want to implement additional mitigation techniques (i.e. enforce policies) or to not use password-based inner methods. > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Wednesday, September 01, 2010 9:34 AM > To: Hoeper Katrin-QWKN37 > Cc: Glen Zorn; Bernard Aboba; emu@ietf.org > Subject: Re: [Emu] security paper on tunneled authentication >=20 > Hoeper Katrin-QWKN37 wrote: > > I will check the current draft for conflicts and, if necessary, propose > > changes. >=20 > I think that the main issue with the draft is that it requires > tunneled methods to allow for password authentication. Your analysis > paper says that password methods cannot be made resistant to these attacks. >=20 > If that is right, then I don't think there is anything to do in the > draft. >=20 > Alan DeKok. From jsalowey@cisco.com Wed Sep 1 08:51:26 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BADDF3A6886 for ; Wed, 1 Sep 2010 08:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.26 X-Spam-Level: X-Spam-Status: No, score=-110.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7Q2Bc8dVvTa for ; Wed, 1 Sep 2010 08:51:21 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 72B703A680E for ; Wed, 1 Sep 2010 08:51:21 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAYTfkyrR7H+/2dsb2JhbACgYHGiXJwCgw2CLASEPoVWgn4 X-IronPort-AV: E=Sophos;i="4.56,304,1280707200"; d="scan'208";a="581865843" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2010 15:51:51 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o81FppUh019161; Wed, 1 Sep 2010 15:51:51 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Sep 2010 08:51:51 -0700 Received: from 10.33.117.78 ([10.33.117.78]) by xmb-sjc-225.amer.cisco.com ([128.107.191.38]) via Exchange Front-End Server email.cisco.com ([128.107.191.87]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Sep 2010 15:51:51 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Wed, 01 Sep 2010 08:51:59 -0700 From: Joe Salowey To: Hoeper Katrin-QWKN37 , Alan DeKok Message-ID: Thread-Topic: [Emu] security paper on tunneled authentication Thread-Index: ActJ4r3YSx2m5lmmR96GxqMH4dfCiwAACeWgAAKtvTo= In-Reply-To: <3A241A6B234BE948B8B474D261FEBC2F08073BB8@de01exm68.ds.mot.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Sep 2010 15:51:51.0871 (UTC) FILETIME=[98232CF0:01CB49ED] Cc: Bernard Aboba , emu@ietf.org Subject: Re: [Emu] security paper on tunneled authentication X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 15:51:26 -0000 I'd be glad to add a reference. On 9/1/10 7:40 AM, "Hoeper Katrin-QWKN37" wrote: > I agree. That's why I was thinking that adding a reference that makes > implementers aware of this problem would be a good idea. Then they can > make an educated decision about whether they want to implement > additional mitigation techniques (i.e. enforce policies) or to not use > password-based inner methods. > > >> -----Original Message----- >> From: Alan DeKok [mailto:aland@deployingradius.com] >> Sent: Wednesday, September 01, 2010 9:34 AM >> To: Hoeper Katrin-QWKN37 >> Cc: Glen Zorn; Bernard Aboba; emu@ietf.org >> Subject: Re: [Emu] security paper on tunneled authentication >> >> Hoeper Katrin-QWKN37 wrote: >>> I will check the current draft for conflicts and, if necessary, > propose >>> changes. >> >> I think that the main issue with the draft is that it requires >> tunneled methods to allow for password authentication. Your analysis >> paper says that password methods cannot be made resistant to these > attacks. >> >> If that is right, then I don't think there is anything to do in the >> draft. >> >> Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Wed Sep 1 09:57:15 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABCA33A67F7 for ; Wed, 1 Sep 2010 09:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.934 X-Spam-Level: X-Spam-Status: No, score=-102.934 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Gg8RyFiMVhI for ; Wed, 1 Sep 2010 09:57:14 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 89F7D3A67F3 for ; Wed, 1 Sep 2010 09:57:14 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C96272022C; Wed, 1 Sep 2010 12:57:44 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 05EFA4761; Wed, 1 Sep 2010 12:57:44 -0400 (EDT) From: Sam Hartman To: "Hoeper Katrin-QWKN37" References: <000001cb497d$ca849fa0$5f8ddee0$@net> <3A241A6B234BE948B8B474D261FEBC2F08073B96@de01exm68.ds.mot.com> <4C7E645D.9090504@deployingradius.com> <3A241A6B234BE948B8B474D261FEBC2F08073BB8@de01exm68.ds.mot.com> Date: Wed, 01 Sep 2010 12:57:43 -0400 In-Reply-To: <3A241A6B234BE948B8B474D261FEBC2F08073BB8@de01exm68.ds.mot.com> (Hoeper Katrin-QWKN's message of "Wed, 1 Sep 2010 10:40:15 -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: Bernard Aboba , emu@ietf.org Subject: Re: [Emu] security paper on tunneled authentication X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 16:57:15 -0000 >>>>> "Hoeper" == Hoeper Katrin-QWKN37 writes: Hoeper> I agree. That's why I was thinking that adding a reference Hoeper> that makes implementers aware of this problem would be a Hoeper> good idea. Then they can make an educated decision about Hoeper> whether they want to implement additional mitigation Hoeper> techniques (i.e. enforce policies) or to not use Hoeper> password-based inner methods. Well, we also want to make sure that if you're using a non-password inner method, then we are not vulnerable to MITM issues. From hartmans@mit.edu Wed Sep 1 10:11:20 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0993A69D8 for ; Wed, 1 Sep 2010 10:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.921 X-Spam-Level: X-Spam-Status: No, score=-102.921 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkyPhxf0d1ik for ; Wed, 1 Sep 2010 10:11:18 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id D45BA3A68E8 for ; Wed, 1 Sep 2010 10:11:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 17B6F2022C; Wed, 1 Sep 2010 13:11:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0D46C4761; Wed, 1 Sep 2010 13:11:48 -0400 (EDT) From: Sam Hartman To: "Hoeper Katrin-QWKN37" References: <3A241A6B234BE948B8B474D261FEBC2F07DFBF82@de01exm68.ds.mot.com> Date: Wed, 01 Sep 2010 13:11:48 -0400 In-Reply-To: <3A241A6B234BE948B8B474D261FEBC2F07DFBF82@de01exm68.ds.mot.com> (Hoeper Katrin-QWKN's message of "Fri, 30 Jul 2010 16:12:58 -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: Lily Chen , emu@ietf.org Subject: [Emu] How does cryptographic binding work X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 17:11:20 -0000 So, this paper makes it clear that I don't understand some of this stuff as well as I thought I did. No surprise there; it's complicated and this has not been my primary area of focus. so let's see if I can be educated. In the part of the world I'm familiar with, we address this problem by authenticating the identity of the outer tunnel as part of the inner tunnel. For example for a TLS-based tunnel we might hash the TLS finish message into the inner method. We don't even try to do anything with plaintext password methods: there's no point you're just kidding yourself. We do try and do something with things like SCRAM (think mschapv2 roughly). We're typically using the tunnel in order to fight against dictionary attacks mounted by observers or to provide session security later. If I'm reading this paper right that's not what we're doing here in EAP. We're taking some quantity from the inner method and binding to that? What's the rationale for that? From jsalowey@cisco.com Wed Sep 1 16:37:59 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABAE53A6A0E for ; Wed, 1 Sep 2010 16:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.276 X-Spam-Level: X-Spam-Status: No, score=-110.276 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qtq+9YEuKazr for ; Wed, 1 Sep 2010 16:37:58 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A7B5A3A6A07 for ; Wed, 1 Sep 2010 16:37:58 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALaAfkyrR7H+/2dsb2JhbACgdHGlFZwcgm4fgiwEhD6FVoJ+h20 X-IronPort-AV: E=Sophos;i="4.56,306,1280707200"; d="scan'208";a="236542681" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 01 Sep 2010 23:38:29 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o81NcTt4011809; Wed, 1 Sep 2010 23:38:29 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Sep 2010 16:38:29 -0700 Received: from 10.33.117.78 ([10.33.117.78]) by xmb-sjc-225.amer.cisco.com ([128.107.191.38]) via Exchange Front-End Server email.cisco.com ([128.107.191.79]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Sep 2010 23:38:28 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Wed, 01 Sep 2010 16:38:29 -0700 From: Joe Salowey To: Sam Hartman , Hoeper Katrin-QWKN37 Message-ID: Thread-Topic: [Emu] How does cryptographic binding work Thread-Index: ActKLse6WErj0m6dqEW7b2cODVkcGw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Sep 2010 23:38:29.0104 (UTC) FILETIME=[C7C9E700:01CB4A2E] Cc: Lily Chen , emu@ietf.org Subject: Re: [Emu] How does cryptographic binding work X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 23:37:59 -0000 The basic reason for this is that EAP methods have a well defined mechanism to output key material. There hasn't been a mechanism to import data into a method, channel bindings may change this. Key generating EAP methods export an MSK. The MSK is then mixed with key material extracted from the TLS keying material to form a combined key. This combined key is then used in a MAC calculation on some data sent within the tunnel. The details vary depending on the method. Typically the MSK exported from the tunnel method also have the inner method MSK mixed in with the TLS key material. There are cases with some EAP methods where data from the TLS tunnel has been used directly in the inner method. This behavior causes differences between the way the method behaves inside the tunnel and outside the tunnel, which may complicate implementations in many cases. EAP tunnel methods typically do not try to do any binding with plaintext basic PAP-like password exchanges. Hope this helps to clarify things. Joe On 9/1/10 10:11 AM, "Sam Hartman" wrote: > > > So, this paper makes it clear that I don't understand some of this stuff > as well as I thought I did. No surprise there; it's complicated and > this has not been my primary area of focus. so let's see if I can be > educated. > > In the part of the world I'm familiar with, we address this problem by > authenticating the identity of the outer tunnel as part of the inner > tunnel. For example for a TLS-based tunnel we might hash the TLS finish > message into the inner method. We don't even try to do anything with > plaintext password methods: there's no point you're just kidding > yourself. We do try and do something with things like SCRAM (think > mschapv2 roughly). We're typically using the tunnel in order to fight > against dictionary attacks mounted by observers or to provide session > security later. > > If I'm reading this paper right that's not what we're doing here in EAP. > We're taking some quantity from the inner method and binding to that? > > What's the rationale for that? > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Wed Sep 1 16:56:07 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFE343A6A0F for ; Wed, 1 Sep 2010 16:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.888 X-Spam-Level: X-Spam-Status: No, score=-102.888 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2hP2LLv0lP0 for ; Wed, 1 Sep 2010 16:56:07 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 178F83A6852 for ; Wed, 1 Sep 2010 16:56:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9D85220411; Wed, 1 Sep 2010 19:56:33 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 47B8E4761; Wed, 1 Sep 2010 19:56:32 -0400 (EDT) From: Sam Hartman To: Joe Salowey References: Date: Wed, 01 Sep 2010 19:56:32 -0400 In-Reply-To: (Joe Salowey's message of "Wed, 01 Sep 2010 16:38:29 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Lily Chen , Sam Hartman , emu@ietf.org Subject: Re: [Emu] How does cryptographic binding work X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 23:56:08 -0000 >>>>> "Joe" == Joe Salowey writes: Joe> The basic reason for this is that EAP methods have a well Joe> defined mechanism to output key material. There hasn't been a Joe> mechanism to import data into a method, channel bindings may Joe> change this. OK, but I'm not sure this quite gets you the properties you want. As best I can tell: * The server wants assurance that if an inner method is somehow lifted out of a tunneled exchange, the inner method cannot be used alone or in a different tunnel. * The client wants assurance that it's talking to a consistent server so that you only end up having to authenticate the server at one level. Impersonating peers to servers and impersonating servers to peers both have value to an attacker in different situations. I think these are the properties you want (And I think the definition in RFC 3748 is a bit under specified) and I'm not sure how what you've described gets that. From jsalowey@cisco.com Wed Sep 1 19:50:45 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC04A3A68D5 for ; Wed, 1 Sep 2010 19:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.292 X-Spam-Level: X-Spam-Status: No, score=-110.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NLm3FnFAFuZ for ; Wed, 1 Sep 2010 19:50:44 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AAC673A68BF for ; Wed, 1 Sep 2010 19:50:44 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHutfkyrR7H+/2dsb2JhbACgeXGkepwNhTkEhD6FVoJ+h20 X-IronPort-AV: E=Sophos;i="4.56,307,1280707200"; d="scan'208";a="582130564" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 02 Sep 2010 02:51:15 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o822pFwv010075; Thu, 2 Sep 2010 02:51:15 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Sep 2010 19:51:15 -0700 Received: from 10.33.117.78 ([10.33.117.78]) by xmb-sjc-225.amer.cisco.com ([128.107.191.38]) via Exchange Front-End Server email.cisco.com ([171.70.151.187]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Sep 2010 02:51:14 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Wed, 01 Sep 2010 19:51:18 -0700 From: Joe Salowey To: Sam Hartman Message-ID: Thread-Topic: [Emu] How does cryptographic binding work Thread-Index: ActKSbdjuQthohmbOkaDMjT36EUuzA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Sep 2010 02:51:15.0067 (UTC) FILETIME=[B5A3CCB0:01CB4A49] Cc: Lily Chen , emu@ietf.org Subject: Re: [Emu] How does cryptographic binding work X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 02:50:46 -0000 On 9/1/10 4:56 PM, "Sam Hartman" wrote: >>>>>> "Joe" == Joe Salowey writes: > > Joe> The basic reason for this is that EAP methods have a well > Joe> defined mechanism to output key material. There hasn't been a > Joe> mechanism to import data into a method, channel bindings may > Joe> change this. > > OK, but I'm not sure this quite gets you the properties you want. > [Joe] What we wanted from this mechanism was to ensure that the tunnel endpoints was the same as the inner method endpoints. > As best I can tell: > > * The server wants assurance that if an inner method is somehow lifted > out of a tunneled exchange, the inner method cannot be used alone or > in a different tunnel. > [Joe] We didn't want to modify the method. The purpose was to restrict the method only to the a particular tunnel type, but we wanted to make sure that the particular instance of method execution wasn't executed in a different tunnel or without a tunnel. > * The client wants assurance that it's talking to a consistent server so > that you only end up having to authenticate the server at one level. > [Joe] For most cases the assumption is that the server is authenticated by the tunnel method. > Impersonating peers to servers and impersonating servers to peers both > have value to an attacker in different situations. > > I think these are the properties you want (And I think the definition in > RFC 3748 is a bit under specified) and I'm not sure how what you've > described gets that. [Joe] I'm not sure if I understand the properties you describe, so I'm not sure if they line up with the goals of making sure the tunnel endpoints are the same as the inner method endpoints. From aland@deployingradius.com Thu Sep 2 06:18:58 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2A43A68EA for ; Thu, 2 Sep 2010 06:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.969 X-Spam-Level: X-Spam-Status: No, score=-101.969 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Or6LlxwiXYaD for ; Thu, 2 Sep 2010 06:18:57 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 3FDFB3A68A9 for ; Thu, 2 Sep 2010 06:18:57 -0700 (PDT) Message-ID: <4C7FA45D.6090807@deployingradius.com> Date: Thu, 02 Sep 2010 15:19:25 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lily Chen , emu@ietf.org Subject: Re: [Emu] How does cryptographic binding work X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 13:18:58 -0000 Sam Hartman wrote: > * The client wants assurance that it's talking to a consistent server so > that you only end up having to authenticate the server at one level. I have always been unsure as to why clients don't tie credentials to a server certificate. Instead, they are usually tied to an SSID. And while clients can verify the servers CA, the CA is usually in a global CA store. i.e. the credentials are only associated with an SSID. If it were possible to tie user credentials to a server certificate, then the clients could validate the server before sending the credentials. For the attack to work on the client, it requires that the client set up an anonymous tunnel with the attacker, and send credentials down that tunnel. If the client were to associate the credentials with a server cert, the attack could be detected. Alan DeKok. From hartmans@mit.edu Thu Sep 2 08:29:03 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5CD3A6A38 for ; Thu, 2 Sep 2010 08:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uagf+JqQiKDf for ; Thu, 2 Sep 2010 08:29:02 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 930013A69BE for ; Thu, 2 Sep 2010 08:29:02 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DCF0D20239; Thu, 2 Sep 2010 11:29:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2C1B24761; Thu, 2 Sep 2010 11:29:26 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <4C7FA45D.6090807@deployingradius.com> Date: Thu, 02 Sep 2010 11:29:26 -0400 In-Reply-To: <4C7FA45D.6090807@deployingradius.com> (Alan DeKok's message of "Thu, 02 Sep 2010 15:19:25 +0200") 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: Lily Chen , Sam Hartman , emu@ietf.org Subject: Re: [Emu] How does cryptographic binding work X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 15:29:03 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Sam Hartman wrote: >> * The client wants assurance that it's talking to a consistent >> server so that you only end up having to authenticate the server >> at one level. Alan> I have always been unsure as to why clients don't tie Alan> credentials to a server certificate. Instead, they are Alan> usually tied to an SSID. And while clients can verify the Alan> servers CA, the CA is usually in a global CA store. Hmm. Android at least seems to let me pick an expected CA for each SSID separately. I don't have EAP here at home so I've not played with the security. That presumably means that wpa_supplicant gives you enough rope under the covers. I can't help the Windows and mac users:-) From wwwrun@rfc-editor.org Fri Sep 3 13:51:27 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFC653A6998 for ; Fri, 3 Sep 2010 13:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJdjhGKxNdTT for ; Fri, 3 Sep 2010 13:51:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id C04EF3A6953 for ; Fri, 3 Sep 2010 13:51:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A8E21E06AE; Fri, 3 Sep 2010 13:51:55 -0700 (PDT) To: dansimon@microsoft.com, bernarda@microsoft.com, rmh@microsoft.com, turners@ieca.com, tim.polk@nist.gov, aland@deployingradius.com, jsalowey@cisco.com, aland@freeradius.org From: RFC Errata System Message-Id: <20100903205155.A8E21E06AE@rfc-editor.org> Date: Fri, 3 Sep 2010 13:51:55 -0700 (PDT) X-Mailman-Approved-At: Mon, 06 Sep 2010 17:18:11 -0700 Cc: min.pae@viasat.com, emu@ietf.org, rfc-editor@rfc-editor.org Subject: [Emu] [Editorial Errata Reported] RFC5216 (2510) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 20:51:27 -0000 The following errata report has been submitted for RFC5216, "The EAP-TLS Authentication Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5216&eid=2510 -------------------------------------- Type: Editorial Reported by: Min Pae Section: 3.1 Original Text ------------- The L bit (length included) 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. Corrected Text -------------- The L bit (length included) 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. The L bit MAY be included in all fragments of a fragmented TLS message, but if included the TLS Length MUST represent the entire length of the TLS message. Notes ----- The lack of definition for what to do with the L bit and the TLS length field for TLS fragments other than the first fragment is leaving the door open to divergent behavior for whether the L bit and length field are included, what the length contains if they're included, and how to interpret it. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5216 (draft-simon-emu-rfc2716bis-13) -------------------------------------- Title : The EAP-TLS Authentication Protocol Publication Date : March 2008 Author(s) : D. Simon, B. Aboba, R. Hurst Category : PROPOSED STANDARD Source : EAP Method Update Area : Security Stream : IETF Verifying Party : IESG From jkmalinen@gmail.com Tue Sep 7 00:04:40 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5E33A68C8 for ; Tue, 7 Sep 2010 00:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2yJqR8k531G for ; Tue, 7 Sep 2010 00:04:39 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 3A6473A68A9 for ; Tue, 7 Sep 2010 00:04:39 -0700 (PDT) Received: by vws10 with SMTP id 10so4332007vws.31 for ; Tue, 07 Sep 2010 00:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nHHTAi3Y3oEAIm8QRRhbEoi8yUObxc2kbkD8qu5K6EI=; b=KzEy+Qq1ZX106p/CzrpxKhh8UOmxLI5lVjgHibV1mmYmDZGDLInxBjBRv3kbcrzNAD dl/C/MooOjgxpl5Vd1gpRQSUlTH2jngEDkdAp1GCNdThfVa2rm+v4C6YHc2HtSL1tQml 45doK21zUUSy5UL3RVvG/X0ntDjJqR/gfD7lI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gCyoIQnRHB7OiVtTUMuRtqtAyvN/GcVQNrmuctVV+dkVozkXgj1/Atbuj3pQpkNkz2 L2BIYY5trbnj3j68QuIphBHBKN49uiy5fJpI/xN/YJ+1FUUCIlXxUhfGoEcMkbzD3v2h jdOVCD49euwOJv8q3PRBSSBfofhOfuCG2hMR8= MIME-Version: 1.0 Received: by 10.220.127.101 with SMTP id f37mr1834020vcs.122.1283843107418; Tue, 07 Sep 2010 00:05:07 -0700 (PDT) Received: by 10.220.200.10 with HTTP; Tue, 7 Sep 2010 00:05:07 -0700 (PDT) In-Reply-To: <20100903205155.A8E21E06AE@rfc-editor.org> References: <20100903205155.A8E21E06AE@rfc-editor.org> Date: Tue, 7 Sep 2010 10:05:07 +0300 Message-ID: From: Jouni Malinen To: RFC Errata System Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 07 Sep 2010 07:30:41 -0700 Cc: emu@ietf.org, tim.polk@nist.gov, min.pae@viasat.com, bernarda@microsoft.com, rmh@microsoft.com, aland@freeradius.org, dansimon@microsoft.com Subject: Re: [Emu] [Editorial Errata Reported] RFC5216 (2510) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 07:04:40 -0000 On Fri, Sep 3, 2010 at 11:51 PM, RFC Errata System wrote: > http://www.rfc-editor.org/errata_search.php?rfc=3D5216&eid=3D2510 > Section: 3.1 Please note that similar language exists in other places of the document, too (2.1.5 and 3.2) and the same comments should apply to them. > Original Text > ------------- > The L bit (length included) 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. > > Corrected Text > -------------- > The L bit (length included) 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. =C2=A0The L bit MAY be included > in all fragments of a fragmented TLS message, but if included the > TLS Length MUST represent the entire length of the TLS message. This would still leave some potential uses of the L bit undefined. These two sentences cover only fragmented TLS messages. What about TLS messages that are not fragmented? It should also be noted that the proposed text would make RFC 5216 (EAP-TLS) inconsistent with RFC 5281 (EAP-TTLS) as far as fragmentation is concerned. I do not think that that would be a good idea since it is possible to share same implementation for handling fragmentation/reassembly of various TLS-based EAP methods (EAP-TLS, EAP-TTLS, EAP-PEAP, EAP-FAST). RFC 5281 disallows use of the L bit in the fragments other than the first one. In addition, it does actually cover the not fragmented message case, too: If there are multiple fragments, the first fragment MUST have the L bit set and include the length of the entire raw message prior to fragmentation. Fragments other than the first MUST NOT have the L bit set. Unfragmented messages MAY have the L bit set and include the length of the message (though this information is redundant). My preference would be for RFC 5216 to follow this design, but I don't think I would be willing to call this change "editorial".. Are there any known EAP-TLS implementations that actually use the L bit in fragments other than the first one? Would that interoperate with other EAP-TLS implementations? - Jouni From min.pae@viasat.com Tue Sep 7 14:44:47 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0523A6867 for ; Tue, 7 Sep 2010 14:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMc4H2my-q7v for ; Tue, 7 Sep 2010 14:44:46 -0700 (PDT) Received: from viasat.com (bateleur.viasat.com [199.106.52.160]) by core3.amsl.com (Postfix) with ESMTP id EDC2A3A6825 for ; Tue, 7 Sep 2010 14:44:45 -0700 (PDT) Received: from ([172.20.1.71]) by bateleur.viasat.com with ESMTP id H6GMFJ1.27785171; Tue, 07 Sep 2010 14:45:02 -0700 Received: from VCAEXCH01.hq.corp.viasat.com ([172.20.1.70]) by VCAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Sep 2010 14:45:01 -0700 Received: from 172.20.1.71 ([172.20.1.71]) by VCAEXCH01.hq.corp.viasat.com ([172.20.1.70]) with Microsoft Exchange Server HTTP-DAV ; Tue, 7 Sep 2010 21:45:01 +0000 References: <20100903205155.A8E21E06AE@rfc-editor.org> Content-Transfer-Encoding: quoted-printable Thread-Topic: [Emu] [Editorial Errata Reported] RFC5216 (2510) Thread-Index: ActO1ex2c4tMKOhyS0OJARSJx/4vkA== From: "Pae, Min" Content-Type: text/plain; charset="us-ascii" In-Reply-To: Message-ID: Date: Tue, 7 Sep 2010 14:45:16 -0700 To: "Jouni Malinen" MIME-Version: 1.0 (iPhone Mail 8A306) X-OriginalArrivalTime: 07 Sep 2010 21:45:01.0877 (UTC) FILETIME=[ECD7FE50:01CB4ED5] X-Mailman-Approved-At: Thu, 09 Sep 2010 08:47:19 -0700 Cc: emu@ietf.org, tim.polk@nist.gov, bernarda@microsoft.com, rmh@microsoft.com, aland@freeradius.org, dansimon@microsoft.com, RFC Errata System Subject: Re: [Emu] [Editorial Errata Reported] RFC5216 (2510) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 23:50:40 -0000 I agree that the text I proposed does not take other TLS based methods into a= ccount. The AAA vendor that we are working with does include the length in f= ragments other than the first, but we are working with them to get this addr= essed. I classified the errata as editorial because I didn't think the proposed tex= t redefines anything about the protocol. If your comment about restricting t= he inclusion of the length field in fragments other than the first is includ= ed, you are probably correct that this shouldn't be classified as editorial.= =20 On Sep 7, 2010, at 12:05 AM, Jouni Malinen wrote: > On Fri, Sep 3, 2010 at 11:51 PM, RFC Errata System > wrote: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5216&eid=3D2510 >=20 >> Section: 3.1 >=20 > Please note that similar language exists in other places of the > document, too (2.1.5 and 3.2) and the same comments should apply to > them. >=20 >> Original Text >> ------------- >> The L bit (length included) 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. >>=20 >> Corrected Text >> -------------- >> The L bit (length included) 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. The L bit MAY be included >> in all fragments of a fragmented TLS message, but if included the >> TLS Length MUST represent the entire length of the TLS message. >=20 > This would still leave some potential uses of the L bit undefined. > These two sentences cover only fragmented TLS messages. What about TLS > messages that are not fragmented? >=20 > It should also be noted that the proposed text would make RFC 5216 > (EAP-TLS) inconsistent with RFC 5281 (EAP-TTLS) as far as > fragmentation is concerned. I do not think that that would be a good > idea since it is possible to share same implementation for handling > fragmentation/reassembly of various TLS-based EAP methods (EAP-TLS, > EAP-TTLS, EAP-PEAP, EAP-FAST). >=20 > RFC 5281 disallows use of the L bit in the fragments other than the > first one. In addition, it does actually cover the not fragmented > message case, too: >=20 > If there are multiple fragments, the first fragment MUST have the L > bit set and include the length of the entire raw message prior to > fragmentation. Fragments other than the first MUST NOT have the L > bit set. Unfragmented messages MAY have the L bit set and include > the length of the message (though this information is redundant). >=20 > My preference would be for RFC 5216 to follow this design, but I don't > think I would be willing to call this change "editorial".. Are there > any known EAP-TLS implementations that actually use the L bit in > fragments other than the first one? Would that interoperate with other > EAP-TLS implementations? >=20 > - Jouni From jsalowey@cisco.com Thu Sep 16 14:13:07 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2593A6970 for ; Thu, 16 Sep 2010 14:13: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz2zNBYVjTs3 for ; Thu, 16 Sep 2010 14:13:04 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 2012C3A6974 for ; Thu, 16 Sep 2010 14:13:04 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALMlkkyrRN+K/2dsb2JhbACiEXGqYZxAhUEEhEuFZIJ+ X-IronPort-AV: E=Sophos;i="4.56,378,1280707200"; d="scan'208";a="187835178" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 16 Sep 2010 21:13:29 +0000 Received: from [10.33.249.222] ([10.33.249.222]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o8GLDSaE025027 for ; Thu, 16 Sep 2010 21:13:29 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Sep 2010 14:13:43 -0700 Message-Id: <2581B072-7FF7-4CAC-9001-D0A2CBBC26E2@cisco.com> To: emu@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Emu] Comments on draft-ietf-emu-chbind-05 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 21:13:07 -0000 I like the direction the document is taking. I think the following are = the biggest open issues in the document; - Refinement of use cases - not all of the examples in the document are = compelling (see detailed comments below). These need refining and we = should also look for use cases dealing with 802.11u and perhaps using = EAP in other environments (ABFAB). =20 - Protocol definition - there is general consensus that we should = include the protocol definition within this document. I think it would = be good to flesh out the following approach in the document to see if it = meets working group expectations: define a Channel-Binding-TLV to hold = channel binding data; define channel binding data as diameter AVPs. = The protocol should define attributes for at least one case (probably = 802.11) and provide guidance for creating binds for other EAP/AAA usages = in other follow-on documents. =20 Detailed comments follow: 1. Introduction I think it would be good discuss that the problem is manifested when the = same set of credentials are used to access different classes or types of = services. This is discussed later in section 4.3, but I believe this = to be fundamental to channel binding problem and should be discussed in = the introduction. When the EAP server is centralized and accessed from = different for different services it typically uses the same set of = credentials to authenticate itself to the peer for each service so the = peer cannot differentiate between services. The server could also = attempt to detect any discrepancy by forcing the client to use different = credentials for each services. Using different credentials for each = different class or type of service has numerous problems.=20 2. Section 3 In the Enterprise network case its not clear to me that channel bindings = alone can alleviate this attack. The peer does not know which VLAN its = traffic is going to, it just knows the SSID. Likewise the AAA server = does not know what VLAN the authenticator is switching the peers traffic = to, it only knows what it told the authenticator to do, if the = authenticator is compromised, it need not comply. It is possible that = this may be detected by another part of the infrastructure, but this = would involve more than the authenticator, peer and AAA. =20 One mechanism that deployment use to avoid the "enterprise and provider" = problem today is to use different credentials for remote access versus = enterprise access. This is often not ideal, but it addresses the = problem.=20 3. Section 4 It could be possible to use EAP channel bindings to address some more = traditional channel bindings uses cases by carrying information from the = lower layer or encapsulating tunnel in the transported method.=20 4. Section 4.2 This section states that for the system to function the EAP server has = to have access to a local database. THis doesn't sound right to me. I = wouldn't expect many systems would be designed this way. The accuracy = of the AAA attributes would be verified by the AAA server that hosts the = EAP server, but perhaps this is too fine a distinction for this = document. I would expect any processing of AAA attributes to be done = in the AAA server.=20 5. Section 4.3 I don't think the RSNIE containing security parameters is not currently = carried in a AAA attribute. Do we still want to use this as an = example? I'm not sure what the 3rd paragraph is getting at. The peer usually = does not have any clue as to what specific VLANs are in use, so its not = clear to me what this is saying. =20 This section probably should briefly cover that in some cases it is = possible that the EAP-Server is collocated with the authenticator and = AAA is not involved. =20 6. Section 5.1 In this section I have the same comment about the EAP Server accessing = the database. I think the EAP server interfaces with AAA and AAA = maintains and process the AAA attributes. Conceptually the result is the = same, so maybe its not such a big deal. Maybe it would be helpful to = describe that other architectural choices are valid. Separating out = the i2 consistency check form the i1 validation could allow the = consistency of some attributes to be checked on a different AAA server.=20= 7. Section 7 Called-Station-ID needs to reference RFC 3580 Since 802.11u is dealing with advertising services we need someone = familiar with 11u to check to see if there is anything we need to = include here.=20 If we are carrying username it seems we would want to know what NAI the = client specified? 8. Section 8 General question: If the attributes are not used in section 7 should = they be included in section 8? If an attribute is include in section 7 = shouldn't it be included in section 8? I think we may need to be more specific about what we want the username = comparison to do. For example are we comparing against the = authenticated name? WHat about the realm part or other decoration? =20 Called station Id and calling station ID formats depend upon the = media/port type. =20 From aland@deployingradius.com Fri Sep 17 03:14:57 2010 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926043A692B for ; Fri, 17 Sep 2010 03:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.042 X-Spam-Level: X-Spam-Status: No, score=-102.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2XWwVcoDTBp for ; Fri, 17 Sep 2010 03:14:44 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 4F0763A68F6 for ; Fri, 17 Sep 2010 03:14:44 -0700 (PDT) Message-ID: <4C933FAB.9090003@deployingradius.com> Date: Fri, 17 Sep 2010 12:15:07 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "emu@ietf.org" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: [Emu] [Fwd: NomCom 2010-2011: Call for More Nominations] X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 10:14:57 -0000 ---------- Forwarded message ---------- From: NomCom Chair Date: Thu, Sep 16, 2010 at 6:26 PM Subject: NomCom 2010-2011: Call for More Nominations To: IETF Announcement list Hi Folks, Nominations have slowed down dramatically, so this update is to enlist the community in an effort to pick up the pace. We are very far behind in nominations for all the open positions but in particular we need nominations for the IESG and IAOC open positions. There have been no nominations received (other than for the incumbents) in INT, RAI, and RTG, and only 1 for OPS. Likewise, in IAOC there have been no nominations submitted other than the incumbent. The acceptance rates of those nominated has also been very slow. In order to initiate the open list of willing nominees we are in need of a reasonable number of acceptances, and due to the low number of nominees and acceptances have delayed the start date for publishing the first open list to September 20. So if you have been nominated and are willing to serve, but have not yet confirmed this by email back to the NomCom, please do so as soon as possible. We need Community input and participation! We cannot properly execute the task of selecting the best candidates for these positions with so few nominations and acceptances. So, please consider making nominations for the open positions, in particular those for which we have so few nominations it takes just a few minutes of your time. Right now, we just need the names/email addresses. Why do we need more nominations? Well, even if you think a willing incumbent is doing a very good job and should be returned, his or her ability to serve again might be impacted by unforeseen circumstances between now and March. NomCom needs to consider multiple nominees to be prepared in the event one or more candidates is unable to serve come next March and to ensure we have chosen the best candidate. There are several ways you can help the IETF Nominating Committee. - You may nominate yourself. - You can nominate someone you know whom you think would do a good job. Do not worry about whether they might already be nominated. We would much prefer to receive the same nomination several times rather than miss a good person we should consider. How to submit Nominations: -------------------------- The list of positions we need to fill, and the provided Job Descriptions, and forms for nominations, can be found in the call for nominations at: https://datatracker.ietf.org/ann/nomcom/2468/ You may enter a nomination by going to the following URL https://wiki.tools.ietf.org/group/nomcom/10/nominate You may also nominate someone by sending an email to nomcom10@ietf.org and giving us their name, email address and the open position you are nominating them for. We will take care of the rest. If you are asked for a user name and password, use an existing ietf login and password. If you need a login and password, request one from the tools page at the following URL http://trac.tools.ietf.org/newlogin Open List: ---------- As you already know, NomCom 2010-2011 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. Feedback Collection: -------------------- Once the open list is available, the entire community will be invited to provide feedback. I will send a further announcement requesting feedback on the nominees, describing how to submit feedback, and how to view the open list of nominees. Thank you, Thomas Walsh Chair, NomCom 2010-2011 nomcom-chair@ietf.org twalsh@juniper.net From root@core3.amsl.com Fri Sep 17 14:15:02 2010 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9C3CF3A68F3; Fri, 17 Sep 2010 14:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100917211502.9C3CF3A68F3@core3.amsl.com> Date: Fri, 17 Sep 2010 14:15:02 -0700 (PDT) Cc: emu@ietf.org Subject: [Emu] I-D Action:draft-ietf-emu-eaptunnel-req-08.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 21:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : Requirements for a Tunnel Based EAP Method Author(s) : K. Hoeper, et al. Filename : draft-ietf-emu-eaptunnel-req-08.txt Pages : 24 Date : 2010-09-17 This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication and the transport of additional data for other purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-eaptunnel-req-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-emu-eaptunnel-req-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-09-17140843.I-D@ietf.org> --NextPart--