From root@core3.amsl.com Wed Oct 7 21:00:02 2009 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 03F7D3A67AB; Wed, 7 Oct 2009 21:00:01 -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: <20091008040002.03F7D3A67AB@core3.amsl.com> Date: Wed, 7 Oct 2009 21:00:02 -0700 (PDT) Cc: emu@ietf.org Subject: [Emu] I-D Action:draft-ietf-emu-eaptunnel-req-04.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: Thu, 08 Oct 2009 04:00: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-04.txt Pages : 24 Date : 2009-10-07 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-04.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-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-07204633.I-D@ietf.org> --NextPart-- From jsalowey@cisco.com Thu Oct 15 11:09:33 2009 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 24B5628C182 for ; Thu, 15 Oct 2009 11:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 ZNo6pgJHNab4 for ; Thu, 15 Oct 2009 11:09:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 04BAA28C16D for ; Thu, 15 Oct 2009 11:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=250; q=dns/txt; s=sjiport01001; t=1255630172; x=1256839772; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Joseph=20Salowey=20(jsalowey)"=20|Subject:=20EMU=20meeting=20at=20IETF=2076|Date:=20 Thu,=2015=20Oct=202009=2011:09:12=20-0700|Message-ID:=20< AC1CFD94F59A264488DC2BEC3E890DE508E8AAF5@xmb-sjc-225.amer .cisco.com>|To:=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable; bh=FuQ4MDIcivUb4Av0e5AVMDHXH1r3k8cLXOWjD5FX2vA=; b=r4gYYYW1/wMolRlfKXy405A/saMiPjNKPxj5EHQwZTx6FwKDZmLHEy+c YJQs2iazgG3BC1v7GU0sTFf1KVrzGKtNMWaxj3eST79mLCSomPi14np6i df8Wd/uhRZl5CSHy4xR0l49kcwfX6rWrhHLuOqu7hIhjvcUoynjBL3rXi 4=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFcC10qrR7H+/2dsb2JhbADBb5hJhDAE X-IronPort-AV: E=Sophos;i="4.44,567,1249257600"; d="scan'208";a="256621098" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 15 Oct 2009 18:09:32 +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 n9FI9LYP005737 for ; Thu, 15 Oct 2009 18:09:32 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.3959); Thu, 15 Oct 2009 11:09:15 -0700 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: Thu, 15 Oct 2009 11:09:12 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EMU meeting at IETF 76 Thread-Index: AcpNwpkyZq+jlAWdRCuVLaj/9thtUw== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 15 Oct 2009 18:09:16.0008 (UTC) FILETIME=[9B6CE680:01CA4DC2] Subject: [Emu] EMU meeting at IETF 76 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, 15 Oct 2009 18:09:33 -0000 On the DRAFT agenda EMU is scheduled to meet on MONDAY, November 9, 2009 1300-1500 Afternoon Session I Acacia 1 SEC emu EAP Method Update WG=20 Let me know if you have any items you would like to add to the agenda. Thanks, Joe From Pascal.Urien@enst.fr Thu Oct 15 11:35:11 2009 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 C0C343A67B1 for ; Thu, 15 Oct 2009 11:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 wHoNk01kYBHj for ; Thu, 15 Oct 2009 11:35:11 -0700 (PDT) Received: from smtp2.enst.fr (revol2.enst.fr [137.194.2.14]) by core3.amsl.com (Postfix) with ESMTP id C79FD3A672E for ; Thu, 15 Oct 2009 11:35:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 12D26B8C9A; Thu, 15 Oct 2009 20:35:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from PC-de-pascal.enst.fr (sony-urien.enst.fr [137.194.164.119]) by smtp2.enst.fr (Postfix) with ESMTP id BFE86B89BF; Thu, 15 Oct 2009 20:35:11 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Oct 2009 20:35:01 +0200 To: "Joseph Salowey (jsalowey)" , From: Pascal Urien In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20091015183511.BFE86B89BF@smtp2.enst.fr> Subject: Re: [Emu] EMU meeting at IETF 76 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, 15 Oct 2009 18:35:11 -0000 Hi Joe, I would like a slot to present with Christophe Kiennert the draft draft-urien-kiennert-emu-bio Version: 00 Staging URL: http://www.ietf.org/staging/draft-urien-kiennert-emu-bio-00.txt Title: EAP BIO Creation_date: 2009-10-15 WG ID: Indvidual Submission Number_of_pages: 18 Abstract: EAP-TTLS is an EAP method that provides secured authentication as described in RFC 5281. This method makes generally use of two phases in order to complete authentication. The first one consists in the authentication of the TTLS server to the client, established by a TLS handshake between the client and the TTLS server. The handshake may be either mutual or one-way. The authentication of the client to the server may then be negotiated during phase two of EAP-TTLS, thanks to widely-deployed authentication mechanisms such as CHAP, PAP, MS-CHAP or MS-CHAP-V2. The purpose of EAP-BIO is to define how to use a biometric authentication mechanism during phase two of EAP-TTLS. This authentication mechanism ranges from physiological characteristics such as fingerprint identification, to behavioral characteristics such as voice or signature analysis. Hence, EAP-BIO combines the security features of EAP-TTLS and biometric authentication. Best Regards Pascal At 20:09 15/10/2009, Joseph Salowey (jsalowey) wrote: >On the DRAFT agenda EMU is scheduled to meet on MONDAY, November 9, 2009 > >1300-1500 Afternoon Session I > >Acacia 1 SEC emu EAP Method Update WG > >Let me know if you have any items you would like to add to the agenda. > >Thanks, > >Joe >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www.ietf.org/mailman/listinfo/emu From mccann.stephen@googlemail.com Tue Oct 20 01:23:57 2009 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 EEDC23A6A06 for ; Tue, 20 Oct 2009 01:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 w1VmUS9Rm+Ot for ; Tue, 20 Oct 2009 01:23:57 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id DAA6F3A69FD for ; Tue, 20 Oct 2009 01:23:56 -0700 (PDT) Received: by fxm18 with SMTP id 18so6100857fxm.37 for ; Tue, 20 Oct 2009 01:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=OxGPMosX7t6YqlRT+PsZ8nHbLmfZMYrLSh1x2lxCjpE=; b=OHJTCGcoZ1yfqFC+LE0I5FaTICEJxFEOjK4wHl06OH1PkKJuAsphhfF3s+InUk8hL1 Q9PRsITeSSZWi+iVEnHe7j9AJZyUXwjw81yFnQsJZJj4j74AJaQJRiugPmoF2RcXlQ0+ A3X7t41L78hr1vb0wZ7jrwSNGKBxVXyQ9diO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Agfy6ujOT7p247TB0kbqvj5iVn5dQKp98gUrZ7W/Ix4jtXAPjVxZ73/d8qevD6OKoJ Sm+QYnvmOicx6Mke/ozP/ssQSsVEEvA9b8WltPYzWOxwmV/fjjvlud4Pc+5xv4n6JTO0 LRLlAlD39zE5O5t4FgA5dtIUnn/X6jHNITQ5I= MIME-Version: 1.0 Received: by 10.204.34.83 with SMTP id k19mr6021366bkd.96.1256027041476; Tue, 20 Oct 2009 01:24:01 -0700 (PDT) Date: Tue, 20 Oct 2009 09:24:01 +0100 Message-ID: From: Stephen McCann To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Emu] Session Policy using EAP internet draft available 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, 20 Oct 2009 08:23:58 -0000 Dear all, An internet draft for Session Policy using EAP is now posted at: http://www.ietf.org/id/draft-mccann-session-policy-framework-using-eap-00.txt This document specifies a framework for implementing a session policy channel using EAP and builds on the presentation I made at the July 2009 (Stockholm) meeting. I have asked Joe for a presentation slot at the November 2009 (Hiroshima) meeting. Kind regards Stephen McCann Research In Motion Ltd From Pasi.Eronen@nokia.com Tue Oct 20 02:59:41 2009 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 AF01F3A6889 for ; Tue, 20 Oct 2009 02:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 o0Jy6IYJ9WHd for ; Tue, 20 Oct 2009 02:59:41 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 869C13A67F8 for ; Tue, 20 Oct 2009 02:59:40 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9K9xVgu003227 for ; Tue, 20 Oct 2009 12:59:45 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 12:59:33 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 12:59:32 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 20 Oct 2009 11:59:32 +0200 From: To: Date: Tue, 20 Oct 2009 11:59:31 +0200 Thread-Topic: New Liaison Statement, "Draft revised Recommendation ITU-T X.1034, Guideline on extensible authentication protocol based authentication and key management in a data communication network" Thread-Index: AcpOhAszAkYpTga2RbGbEkw1OltEvQC5+TDA Message-ID: <808FD6E27AD4884E94820BC333B2DB773C09A90A6C@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Oct 2009 09:59:32.0584 (UTC) FILETIME=[059AF680:01CA516C] X-Nokia-AV: Clean Subject: [Emu] FW: New Liaison Statement, "Draft revised Recommendation ITU-T X.1034, Guideline on extensible authentication protocol based authentication and key management in a data communication network" 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, 20 Oct 2009 09:59:41 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGV4dCBHZW9yZ2VzIFNlYmVr KElUVS1UIFNHIDE3KSBbbWFpbHRvOnRzYnNnMTdAaXR1LmludF0NCj4gU2VudDogMTYgT2N0b2Jl ciwgMjAwOSAyMDoxNA0KPiBUbzogYWxhbmRAZnJlZXJhZGl1cy5vcmc7IGFsYW5kQGRlcGxveWlu Z3JhZGl1cy5jb207IGpzYWxvd2V5QGNpc2NvLmNvbQ0KPiBDYzogRXJvbmVuIFBhc2kgKE5va2lh LU5SQy9IZWxzaW5raSk7IHRpbS5wb2xrQG5pc3QuZ292OyBwYWZAY2lzY28uY29tOw0KPiB0c2Jz ZzE3QGl0dS5pbnQ7IHBtd2VzaWd3YUB1Y2MuY28udWc7IGh5eW91bUBzY2guYWMua3INCj4gU3Vi amVjdDogTmV3IExpYWlzb24gU3RhdGVtZW50LCAiRHJhZnQgcmV2aXNlZCBSZWNvbW1lbmRhdGlv biBJVFUtVA0KPiBYLjEwMzQsIEd1aWRlbGluZSBvbiBleHRlbnNpYmxlIGF1dGhlbnRpY2F0aW9u IHByb3RvY29sIGJhc2VkDQo+IGF1dGhlbnRpY2F0aW9uIGFuZCBrZXkgbWFuYWdlbWVudCBpbiBh IGRhdGEgY29tbXVuaWNhdGlvbiBuZXR3b3JrIg0KPiANCj4gDQo+IFRpdGxlOiBEcmFmdCByZXZp c2VkIFJlY29tbWVuZGF0aW9uIElUVS1UIFguMTAzNCwgR3VpZGVsaW5lIG9uDQo+IGV4dGVuc2li bGUgYXV0aGVudGljYXRpb24gcHJvdG9jb2wgYmFzZWQgYXV0aGVudGljYXRpb24gYW5kIGtleQ0K PiBtYW5hZ2VtZW50IGluIGEgZGF0YSBjb21tdW5pY2F0aW9uIG5ldHdvcmsNCj4gU3VibWlzc2lv biBEYXRlOiAyMDA5LTEwLTE2DQo+IFVSTCBvZiB0aGUgSUVURiBXZWIgcGFnZToNCj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9wdWJsaWMvbGlhaXNvbl9kZXRhaWwuY2dpP2RldGFpbF9p ZD01OTgNCj4gUGxlYXNlIHJlcGx5IGJ5IDIwMTAtMDMtMzENCj4gDQo+IEZyb206IEdlb3JnZXMg U2ViZWsoSVRVLVQgU0cgMTcpIDx0c2JzZzE3QGl0dS5pbnQ+DQo+IFRvOiBJRVRGIEVNVSBXb3Jr aW5nIEdyb3VwKGFsYW5kQGZyZWVyYWRpdXMub3JnLA0KPiBhbGFuZEBkZXBsb3lpbmdyYWRpdXMu Y29tLCBqc2Fsb3dleUBjaXNjby5jb20pDQo+IENjOiBwYXNpLmVyb25lbkBub2tpYS5jb20NCj4g dGltLnBvbGtAbmlzdC5nb3YNCj4gcGFmQGNpc2NvLmNvbQ0KPiBSZXBvbnNlIENvbnRhY3Q6IHRz YnNnMTdAaXR1LmludA0KPiBUZWNobmljYWwgQ29udGFjdDogcG13ZXNpZ3dhQHVjYy5jby51Zw0K PiBoeXlvdW1Ac2NoLmFjLmtyDQo+IFB1cnBvc2U6IEZvciBjb21tZW50DQo+IEJvZHk6IFBsZWFz ZSBmaW5kIGF0dGFjaGVkIGEgbGlhaXNvbiBzdGF0ZW1lbnQgYWdyZWVkIHRvIGF0IHRoZQ0KPiBT ZXB0ZW1iZXIgMjAwOSBTdHVkeSBHcm91cCAxNyAoU2VjdXJpdHkpIG1lZXRpbmcuDQo+IEF0dGFj aG1lbnQocyk6DQo+ICAgICAgQ09NIDE3LUxTIDQ3DQo+IChodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvY3VtZW50cy9MSUFJU09OL2ZpbGU3MTMucGRmKQ0KPiAgICAgIEF0dGFjaG1lbnQg dG8gQ09NIDE3LUxTIDQ3DQo+IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvY3VtZW50 cy9MSUFJU09OL2ZpbGU3MTQucGRmKQ0KPiANCj4gDQoNCg== From root@core3.amsl.com Thu Oct 22 15:30:03 2009 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BC8423A6951; Thu, 22 Oct 2009 15:30:03 -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: <20091022223003.BC8423A6951@core3.amsl.com> Date: Thu, 22 Oct 2009 15:30:03 -0700 (PDT) Cc: emu@ietf.org Subject: [Emu] I-D Action:draft-ietf-emu-chbind-04.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: Thu, 22 Oct 2009 22:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : Channel Binding Support for EAP Methods Author(s) : C. Clancy, K. Hoeper Filename : draft-ietf-emu-chbind-04.txt Pages : 23 Date : 2009-10-22 This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-emu-chbind-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-22151538.I-D@ietf.org> --NextPart-- From khoeper@motorola.com Thu Oct 22 15:41:22 2009 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 EBD653A67DA for ; Thu, 22 Oct 2009 15:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 lcwHIVctZLAS for ; Thu, 22 Oct 2009 15:41:21 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id B58343A67C0 for ; Thu, 22 Oct 2009 15:41:21 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1256251290!30953386!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 26364 invoked from network); 22 Oct 2009 22:41:30 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Oct 2009 22:41:30 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id n9MMfUcf001576 for ; Thu, 22 Oct 2009 15:41:30 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id n9MMfUWk018173 for ; Thu, 22 Oct 2009 17:41:30 -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 n9MMfOMQ018152 for ; Thu, 22 Oct 2009 17:41:29 -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: Thu, 22 Oct 2009 18:41:03 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F069EEC81@de01exm68.ds.mot.com> In-Reply-To: <20091022223003.BC8423A6951@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] I-D Action:draft-ietf-emu-chbind-04.txt Thread-Index: AcpTZ03ahNzjWtjySRarvkpntdpd+AAARUQw References: <20091022223003.BC8423A6951@core3.amsl.com> From: "Hoeper Katrin-QWKN37" To: X-CFilter-Loop: Reflected Subject: Re: [Emu] I-D Action:draft-ietf-emu-chbind-04.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: Thu, 22 Oct 2009 22:41:23 -0000 Hi all, I just submitted a new version of the "Channel Binding Support for EAP Methods" draft (http://www.ietf.org/id/draft-ietf-emu-chbind-04.txt). This version addresses the recent discussions on the list. The main problem seemed to be the scope of the -03 version because it included authorization capabilities, i.e. channel bindings were used to verify whether a NAS is *authorized* to provide an advertized service. The new -04 draft has re-focused the scope to the original purpose of channel bindings, namely preventing the lying NAS as well as the lying provider problem. The primary changes are in Section 1 (new more limited scope), Section 5.2 (removed authorization checks), and Section 10 (set up of policy database no longer needed). In addition Section 7.2.2 IEEE 802.11s was removed based on Bernard's comment, who pointed out that the referenced attribute no longer exists in the 11s draft. Please read the new draft before the meeting in Hiroshima (in less than 3 weeks!). I believe the new draft addresses all open issues and is now ready for WGLC. Best regards, Katrin > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, October 22, 2009 5:30 PM > To: i-d-announce@ietf.org > Cc: emu@ietf.org > Subject: [Emu] I-D Action:draft-ietf-emu-chbind-04.txt >=20 > 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. >=20 >=20 > Title : Channel Binding Support for EAP Methods > Author(s) : C. Clancy, K. Hoeper > Filename : draft-ietf-emu-chbind-04.txt > Pages : 23 > Date : 2009-10-22 >=20 > This document defines how to implement channel bindings for > Extensible Authentication Protocol (EAP) methods to address the lying > NAS as well as the lying provider problem. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From jsalowey@cisco.com Mon Oct 26 20:55:21 2009 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 A29C83A6821 for ; Mon, 26 Oct 2009 20:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 WU94RM0VmbZi for ; Mon, 26 Oct 2009 20:55:20 -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 C861C3A680E for ; Mon, 26 Oct 2009 20:55:20 -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: ApoEAHsL5kqrR7Ht/2dsb2JhbADAR5d7hD8E X-IronPort-AV: E=Sophos;i="4.44,630,1249257600"; d="scan'208";a="418527854" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 27 Oct 2009 03:55:19 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9R3tJD2007263 for ; Tue, 27 Oct 2009 03:55:19 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.3959); Mon, 26 Oct 2009 20:55:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 20:55:18 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF-76 EMU draft agenda Thread-Index: AcpWuUxvJsWxy77wShen+VPKYfW38w== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 27 Oct 2009 03:55:19.0630 (UTC) FILETIME=[4D1F0EE0:01CA56B9] Subject: [Emu] IETF-76 EMU draft agenda X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 03:55:21 -0000 The IETF-76 draft agenda for EMU can be found here: http://www.ietf.org/proceedings/09nov/agenda/emu.txt Please let me know if you have additions or corrections. Thanks, Joe From aland@deployingradius.com Tue Oct 27 13:17:43 2009 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 48B1628C175 for ; Tue, 27 Oct 2009 13:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.567 X-Spam-Level: X-Spam-Status: No, score=0.567 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] 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 is+4ejh+rDXU for ; Tue, 27 Oct 2009 13:17:41 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 06A6A28C14C for ; Tue, 27 Oct 2009 13:17:41 -0700 (PDT) Received: from Thor.local (unknown [74.198.12.3]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 218BD123432F for ; Tue, 27 Oct 2009 21:17:52 +0100 (CET) Message-ID: <4AE7556C.40803@deployingradius.com> Date: Tue, 27 Oct 2009 16:17:48 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "emu@ietf.org" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Emu] Review of draft-ietf-emu-eaptunnel-req-04.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 20:17:43 -0000 Here is my review of the tunnel requirements document. 3. Use Cases To motivate and explain the requirements in this document, a representative set of use cases for the EAP tunnel method are supplied here. The candidate tunnel method is expected to support all of the use cases marked as MUST. The last sentence is unclear. I would suggest saying: ... supplied here. The candidate tunnel method is expected to support all of the use cases that are marked below as "MUST". The use of "is expected" makes it seem like it is not mandatory to follow the following MUST requirements. But it would be awkward to say "it MUST support the MUSTs below". 3.1. Password Authentication ... The combination of the tunnel authentication and password authentication MUST enable mutual authentication. Is the restriction on the *combination*? What is the tunnel authentication method supports mutual authentication, and the password authentication method does not? It may be better to say: The tunnel method MUST support mutual authentication 3.2. Protection of Weak EAP Methods Some existing EAP methods have vulnerabilities that could be eliminated or reduced by running them inside a protected tunnel. For example, a method such as EAP-MD5 does not provide mutual I would suggest deleting the text "a method such as". It is redundant with the previous "For example" phrase. ... In particular, when weak methods are used, security policies enforcing that such methods can only be executed inside a tunnel but never outside one are required to mitigate the attack. This sentence is difficult to parse. I suggest: When weak methods are used, these attacks can be mitigated via security policies that require the method to be used only within a tunnel. ... On the other hand, a technical solution (so-called cryptographic bindings) can be used whenever the inner method is not susceptible to attacks outside a tunnel and derives keying material. Is the final "and" a requirement for cryptographic bindings to be used? 3.3. Chained EAP Methods Several circumstances are best addressed by using chained EAP methods. For example, it may be desirable to authenticate the user and also authenticate the device that he or she is using. Suggest replacing "he or she is using" with a passive voice "is being used". ... Cryptographic binding can be used to bind the results of key generating methods together or to an encompassing tunnel. The previous sentences talk about chained methods rather than "key generating" methods. I suggest replacing the above sentence with: .. Cryptographic binding can be used to bind chained methods together, or to an encompassing tunnel. 3.4. Identity Protection When performing an EAP authentication, the peer may want to protect its identity, only disclosing its identity to a trusted backend authentication server. This helps to maintain the privacy of the peer's identity. This discussion seems redundant. Suggest replacing the text with: When performing an EAP authentication, the peer may want to protect its identity, and only disclose it to a trusted backend authentication server. This process helps to maintain peer privacy. The following text is unclear: The tunnel method MUST support identity protection, ensuring that peer identity is not disclosed to the authenticator and any other intermediaries before the server that terminates the tunnel method. The use of "before" is ambiguous. It could be interpreted as "intermediaries before the server...", rather than "before the tunnel has been terminated" Suggested text: The tunnel method MUST support identity protection, ensuring that peer identity is not disclosed to any intermediaries, or to the authenticator until the tunnel method has been completed. Continuing: 3.5. Anonymous Service Access When network service is provided, it is sometimes desirable for any user to be able to gain access to the network to enable access to limited services emergency communication or troubleshooting information. There are a lot of "to"'s in the above sentence. Suggested text: When network service is provided, it is sometimes desirable for a user to gain network access in order to use limited services emergency communication or access troubleshooting information. This paragraph contains two concepts. (1) requirements, and (2), security analysis derived from the requirements. Therefore, the tunnel method SHOULD allow anonymous peers or server- only authentication, but still derive keys that can be used for link layer security. The tunnel method MAY also allow for the bypass of server authentication processing on the client. Forgoing authentication increases the chance of man-in-the-middle and other types of attacks that can compromise the derived keys used for link layer security. In addition, passwords and other sensitive information must not be disclosed to an unauthenticated or unauthorized server. Suggested text: Therefore, the tunnel method SHOULD allow anonymous peers or server- only authentication, while still deriving keys that can be used for link layer security. The tunnel method MAY also allow for the bypass of server authentication processing on the client. Forgoing user or server authentication increases the chance of man-in-the-middle and other types of attacks that can compromise the derived keys used for link layer security. Therefore, passwords and other sensitive information MUST NOT be disclosed to an unauthenticated server, or to a server that is not authorized to authenticate the user. ... 3.7. Client Authentication During Tunnel Establishment In some cases the peer will have credentials usable to authenticate during tunnel establishment. I'm not sure what that sentence means. Suggest re-wording it. ... 3.8. Extensibility ... One example of a application for extensibility is credential Suggest "an application" ... Another use for extensibility is support for authentication frameworks other than EAP. I presume that this is "within the EAP tunnel". Otherwise, it would seem that the above sentence would permit replacing the tunneled method with non-EAP methods. 4.1.1. RFC Compliance ... The tunnel method MUST meet all the MUST and SHOULD requirements relevant to EAP methods contained in the EAP Key Management Framework [RFC5247] or its successor. Suggest replacing "its successor" with "any successor" ... This will enable the tunnel method to properly fit into the EAP key management framework, maintaining all of the security properties and guarantees of that framework. Suggest adding a qualifier after the first "This". This... what.. ? Maybe "This requirement", or "The above requirement" ... ... This includes algorithms used with certificates presented during tunnel establishment. Again, this ... what? Perhaps the following text: among an extensible set of cryptographic algorithms, such as algorithms used with certificates presented during tunnel establishment. ... 4.2. Tunnel Requirements The following section discusses requirements for TLS Tunnel Establishment. Suggest qualifying this text. Is a TLS method required, or simply suggested? 4.2.1. TLS Requirements The tunnel based method MUST support TLS version 1.2 [RFC5246] and may support earlier versions to enable the possibility of backwards compatibility. The following section discusses requirements for TLS Tunnel Establishment. Suggest deleting the last sentence. It's a repeat of the sentence starting off Section 4.2. All versions of TLS meet these requirements as long as the cipher suites used provide strong authentication, key establishment and data integrity protection. Are we making a statement here that TLS is OK? If the document is a tunnel requirements document only, it may be prudent to avoid making statements about which protocols meet the requirements. 4.2.1.1.3. Tunnel Authentication and Key Establishment A tunnel method MUST provide unidirectional authentication from authentication server to EAP peer and mutual authentication between authentication server and EAP peer. How do these requirements interact with requirements in Section 3.5 for anonymous network access? Do we want to say that the tunneled method SHOULD provide for a standardized "anonymous" user and server? ... The tunnel method MUST provide at least one mandatory to implement cipher suite that provides certificate-based authentication of the server and provides optional certificate-based authentication of the client. Other types of authentication MAY be supported. Does this requirement for certificate-based authentication apply *only* when TLS methods are used? Or is it a wider requirement that the tunneled method MUST support TLS and certificate-based methods? This requirement should be clarified. 4.2.1.2. Tunnel Replay Protection In order to prevent replay attacks on a tunnel protocol, the message authentication MUST be generated using a time-variant input such as timestamps, sequence numbers, nonces, or a combination of these so that any re-use of the authentication data can be detected as invalid. TLS makes use of an 8 byte sequence number to protect against replay. I'm not sure what is the purpose of the last sentence. An example of how to meet the requirements? Something else? It may be simplest to just delete the last sentence. 4.2.1.4. Peer Identity Privacy Is this section necessary? Section 3.4 already mandates identity protection. I suggest moving this text into Section 3.4, or rephrasing it so that it does not overlap with Section 3.4. 4.2.1.5. Session Resumption The tunnel method MUST support TLS session resumption as defined in [RFC5246]. ... if we choose a TLS-based method. If we don't, must it still support TLS session resumption? This comment is just being nit-picky to ensure that particular solutions are not mandated by being written into the requirements document. 4.2.3. Protection of Data External to Tunnel An attacker in the middle ... of what? Suggest rephrasing like: A MitM attack can modify ... 4.3.3. Mandatory and Optional Attributes The payload MUST support marking of mandatory and optional attributes, as well as an attribute used for rejecting mandatory attributes. Mandatory attributes are attributes sent by the requester that the responder is expected to understand and MUST respond to. Given the uncertainty in Diameter about the meaning of "mandatory" attributes, it would be good to be extremely clear in this document. This document should specify the behavior carefully. e.g. "Requestor" and "responder". Does that mean only the peer can mark attributes as mandatory, and the authenticator cannot? The next sentence references a "NAK attribute", without previously defining it. The previous discussion uses the NAK attribute to reject mandatory attributes. If the attributes are mandatory, why are they being rejected? If a responder MUST respond to a mandatory attribute, is the response marked mandatory, too? What kind of response is adequate? While I can guess the intent, it may be better to rephrase the discussion. Suggested text: 4.3.3. Mandatory and Optional Attributes The payload MUST support marking of mandatory and optional attributes, as well as a "NAK" attribute used to communicate disagreements about received attributes. Mandatory attributes are attributes that a receiver MUST process as per the specification. Optional attributes are attributes that a receiver MAY ignore. A receiver MUST process mandatory attributes before optional ones. After an attribute has been processed, it SHOULD be marked as no longer being mandatory. If a receiver does not process a mandatory attribute, it MUST ignore everything else in a request, and it MUST send a NAK attribute in response. Similarly, if a receiver expects a mandatory attribute and does not receive one in a request, it MUST send a NAK attribute in the response that contains the set of attributes it expected to receive. A peer that either sends or receives a NAK attribute MUST treat the session as failing authentication. The NAK attribute MUST support a description of which mandatory attribute is either required, or is not supported. The NAK attribute MUST be otherwise treated as an optional attribute, and it MUST NOT contain a NAK of the NAK attribute, in order to prevent infinite recursion. ... 4.3.4. Vendor Specific Support The payload MUST support communication of an extensible set of vendor-specific attributes. These attributes will be segmented into uniquely identified vendor specific name spaces. They can be used for experiments or vendor specific features. I would suggest adding that vendor-specific attributes SHOULD NOT be marked as being mandatory. Or maybe even MUST NOT be marked as mandatory. 4.3.6. Internationalization of Display Strings The payload MAY provide a standard attribute format that supports international strings. I would suggest changing the MAY to a SHOULD. Not having displayable strings is a problem of great vexation to many administrators. 4.4. EAP Channel Binding Requirements The tunnel method MUST be capable of meeting EAP channel binding requirements described in [I-D.clancy-emu-chbind]. Having a normative reference to an I-D is problematic. I'm not sure that there is any way of avoiding this, however. 4.5.1. Security Many internal EAP methods have the peer send its password in the clear To the EAP server. s/To/to/ 4.5.1.2. Authentication of Server The EAP server MUST be authenticated before the peer can send the clear text password to the server. Suggest replacing "can send" with "sends". 4.5.1.3. Server Certificate Revocation Checking Does this section apply only when TLS && certificate methods are used, or for any method, even non-TLS, and non-certificate? (Just to be nit-picky again) 4.6. Requirements Associated with Carrying EAP Methods The tunnel method MUST be able to carry inner EAP methods without modifying them. EAP methods MUST NOT be redefined inside the tunnel. I would like clarification on the last sentence. Perhaps rephrasing it as a requirement would be good: EAP methods carried inside of the tunnel MUST be identical in nearly all respects to the same method when carried outside of the tunnel. The only permissible difference is that random nonces in a tunneled method SHOULD be calculated instead by cryptographic methods which bind the inner method to the outer tunnel. 4.6.1. Method Negotiation The tunnel method MUST support the protected negotiation of the inner EAP method. It MUST NOT allow the inner EAP method negotiation to be downgraded or manipulated by intermediaries. What is the definition of a "downgraded" EAP method? Perhaps just deleting that word, and leaving it as "manipulated by" would be best. 4.6.3. Cryptographic Binding with the TLS Tunnel While this section is already a bit long, I think it could use additional clarification. It is specifying key derivation functions, and as such, holds the possibility for interoperability issues. ... In particular, all derived keys MUST have a lifetime assigned that does not exceed the lifetime of any key higher in the key hierarchy, and MUST prevent domino effects where a compromise in one part of the system leads to compromises in other parts of the system. This is the first mention of "lifetime". Should we state that there is a requirement to exchange key lifetimes, too? The MUST comment could also be specified in a positive sense: ... In particular, all derived keys MUST have a lifetime is strictly less than the lifetime of any key higher in the key hierarchy, I'm also unsure as to how to prevent domino effects. Is the previous discussion on CTK_n enough of a specification to prevent domino effects? If not, should the definitions of CTK_n be extended? If so, is the following phrase necessary: ... and MUST prevent domino effects where a compromise in one part of the system leads to compromises in other parts of the system. ... 6.1. Cipher Suite Selection TLS supports ... ... Since a tunnel method uses the TLS tunnel to transport data, ... Again, are we mandating TLS? If so, this should be clarified earlier in the document. 6.4. Separation of TLS Tunnel and Inner Authentication Termination ... ... This may not meet the security policy of many environments." There is a stray " in the document. Alan DeKok. From khoeper@motorola.com Wed Oct 28 16:27:12 2009 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 31B5C3A68C7 for ; Wed, 28 Oct 2009 16:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 ylcXKz2RrEuQ for ; Wed, 28 Oct 2009 16:27:10 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 80B553A68E4 for ; Wed, 28 Oct 2009 16:27:09 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1256772443!36056255!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 24417 invoked from network); 28 Oct 2009 23:27:24 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Oct 2009 23:27:24 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n9SNRNCB014566 for ; Wed, 28 Oct 2009 16:27:23 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n9SNRNiA007696 for ; Wed, 28 Oct 2009 18:27:23 -0500 (CDT) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n9SNRMLR007691 for ; Wed, 28 Oct 2009 18:27:22 -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, 28 Oct 2009 19:27:00 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F06A3531F@de01exm68.ds.mot.com> In-Reply-To: <4AE7556C.40803@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Review of draft-ietf-emu-eaptunnel-req-04.txt Thread-Index: AcpXQpsDigELnKw6QgyDa4D7Y/TnFQA3AW7Q References: <4AE7556C.40803@deployingradius.com> From: "Hoeper Katrin-QWKN37" To: "Alan DeKok" , X-CFilter-Loop: Reflected Subject: Re: [Emu] Review of draft-ietf-emu-eaptunnel-req-04.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: Wed, 28 Oct 2009 23:27:12 -0000 Alan, Thanks for your very thorough review. See my comments in-line. (I left a few comments for the other authors ;)) Katrin > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Alan DeKok > Sent: Tuesday, October 27, 2009 3:18 PM > To: emu@ietf.org > Subject: [Emu] Review of draft-ietf-emu-eaptunnel-req-04.txt >=20 >=20 > Here is my review of the tunnel requirements document. >=20 >=20 > 3. Use Cases >=20 > To motivate and explain the requirements in this document, a > representative set of use cases for the EAP tunnel method are > supplied here. The candidate tunnel method is expected to support > all of the use cases marked as MUST. >=20 > The last sentence is unclear. I would suggest saying: >=20 > ... > supplied here. The candidate tunnel method is expected to support > all of the use cases that are marked below as "MUST". >=20 > The use of "is expected" makes it seem like it is not mandatory to > follow the following MUST requirements. But it would be=20 > awkward to say > "it MUST support the MUSTs below". [KH] Agree that your version clarifies this. >=20 >=20 > 3.1. Password Authentication >=20 > ... The > combination of the tunnel authentication and password=20 > authentication > MUST enable mutual authentication. >=20 > Is the restriction on the *combination*? What is the tunnel > authentication method supports mutual authentication, and the password > authentication method does not? >=20 > It may be better to say: >=20 > The tunnel method MUST support mutual authentication [KH] Yes, we wanted to explicitly say that the *combination* (yes, emphasis on combination) of tunnel authentication and password authentication MUST enable mutual authentication. I don't see any problem with this sentence. Password-based authentications typically provide only peer authentication, whereas tunnel protocols typically only server authentication. A tunnel-based EAP method compliant with the draft, MUST enable mutual authentication if password-based authentication is used as an inner method. Password-based authentications are especially highlighted here because there are one of the primary use cases of tunneled authentications. >=20 > 3.2. Protection of Weak EAP Methods >=20 > Some existing EAP methods have vulnerabilities that could be > eliminated or reduced by running them inside a protected=20 > tunnel. For > example, a method such as EAP-MD5 does not provide mutual >=20 >=20 > I would suggest deleting the text "a method such as". It=20 > is redundant > with the previous "For example" phrase. >=20 >=20 [KH] OK > ... In > particular, when weak methods are used, security policies enforcing > that such methods can only be executed inside a tunnel but never > outside one are required to mitigate the attack. >=20 > This sentence is difficult to parse. I suggest: >=20 > When weak methods are used, these attacks can be mitigated via > security policies that require the method to be used only within > a tunnel. >=20 [KH] Sounds good. >=20 > ... On the other hand, > a technical solution (so-called cryptographic bindings) can be used > whenever the inner method is not susceptible to attacks outside a > tunnel and derives keying material. >=20 > Is the final "and" a requirement for cryptographic bindings=20 > to be used? [KH] Yes. >=20 > 3.3. Chained EAP Methods >=20 > Several circumstances are best addressed by using chained EAP > methods. For example, it may be desirable to authenticate the user > and also authenticate the device that he or she is using. >=20 > Suggest replacing "he or she is using" with a passive voice "is being > used". [KH] OK >=20 > ... Cryptographic binding can be used to bind the results of key > generating methods together or to an encompassing tunnel. >=20 > The previous sentences talk about chained methods rather than "key > generating" methods. I suggest replacing the above sentence with: >=20 > .. Cryptographic binding can be used to bind chained methods > together, or to an encompassing tunnel. [KH] I think "...Cryptographic bindings can be used to bind key generating chained methods together, or to an encompassing tunnel" is more accurate because cryptographic bindings are only effective when applied to key generating methods. >=20 > 3.4. Identity Protection >=20 > When performing an EAP authentication, the peer may want to protect > its identity, only disclosing its identity to a trusted backend > authentication server. This helps to maintain the privacy of the > peer's identity. >=20 >=20 > This discussion seems redundant. Suggest replacing the text with: >=20 > When performing an EAP authentication, the peer may want to protect > its identity, and only disclose it to a trusted backend > authentication server. This process helps to maintain=20 > peer privacy. >=20 [KH] OK > The following text is unclear: >=20 > The tunnel method MUST support identity protection, ensuring that > peer identity is not disclosed to the authenticator and any other > intermediaries before the server that terminates the tunnel method. >=20 > The use of "before" is ambiguous. It could be interpreted as > "intermediaries before the server...", rather than "before the tunnel > has been terminated" >=20 > Suggested text: >=20 > The tunnel method MUST support identity protection, ensuring that > peer identity is not disclosed to any intermediaries, or to the > authenticator until the tunnel method has been completed. [KH] As far as I remember, "before" actually referred to the physical location of an intermediary device on the communication path. In any case, I prefer your suggested text :) >=20 > Continuing: >=20 > 3.5. Anonymous Service Access >=20 > When network service is provided, it is sometimes desirable for any > user to be able to gain access to the network to enable access to > limited services emergency communication or troubleshooting > information. >=20 > There are a lot of "to"'s in the above sentence. Suggested text: >=20 > When network service is provided, it is sometimes desirable for a > user to gain network access in order to use > limited services emergency communication or access troubleshooting > information. >=20 [KH] OK > This paragraph contains two concepts. (1) requirements, and (2), > security analysis derived from the requirements. >=20 > Therefore, the tunnel method SHOULD allow anonymous peers=20 > or server- > only authentication, but still derive keys that can be=20 > used for link > layer security. The tunnel method MAY also allow for the bypass of > server authentication processing on the client. Forgoing > authentication increases the chance of man-in-the-middle and other > types of attacks that can compromise the derived keys used for link > layer security. In addition, passwords and other sensitive > information must not be disclosed to an unauthenticated or > unauthorized server. >=20 > Suggested text: >=20 > Therefore, the tunnel method SHOULD allow anonymous peers=20 > or server- > only authentication, while still deriving keys that can be used for > link layer security. The tunnel method MAY also allow for=20 > the bypass > of server authentication processing on the client. >=20 > Forgoing user or server authentication increases the chance of > man-in-the-middle and other types of attacks that can=20 > compromise the > derived keys used for link layer security. Therefore,=20 > passwords and > other sensitive information MUST NOT be disclosed to an > unauthenticated server, or to a server that is not authorized to > authenticate the user. >=20 > ... [KH] Sounds good! >=20 > 3.7. Client Authentication During Tunnel Establishment >=20 > In some cases the peer will have credentials usable to authenticate > during tunnel establishment. >=20 > I'm not sure what that sentence means. Suggest re-wording it. >=20 [KH] It refers to a mutually authenticated tunnel, i.e. the peer authenticates already during the tunnel phase. > ... >=20 > 3.8. Extensibility >=20 > ... > One example of a application for extensibility is credential >=20 > Suggest "an application" [KH] OK >=20 >=20 > ... Another > use for extensibility is support for authentication=20 > frameworks other > than EAP. >=20 > I presume that this is "within the EAP tunnel". Otherwise, it would > seem that the above sentence would permit replacing the=20 > tunneled method > with non-EAP methods. >=20 > 4.1.1. RFC Compliance > ... > The tunnel method MUST meet all the MUST and SHOULD requirements > relevant to EAP methods contained in the EAP Key=20 > Management Framework > [RFC5247] or its successor. >=20 > Suggest replacing "its successor" with "any successor" [KH] OK >=20 > ... This will enable the tunnel > method to properly fit into the EAP key management framework, > maintaining all of the security properties and guarantees of that > framework. >=20 > Suggest adding a qualifier after the first "This". This... what.. ? >=20 > Maybe "This requirement", or "The above requirement" >=20 > ... [KH] OK >=20 > ... This includes > algorithms used with certificates presented during tunnel > establishment. >=20 > Again, this ... what? Perhaps the following text: >=20 > among an extensible set of cryptographic algorithms, such as > algorithms used with certificates presented during tunnel > establishment. >=20 > ... >=20 > 4.2. Tunnel Requirements >=20 > The following section discusses requirements for TLS Tunnel > Establishment. >=20 > Suggest qualifying this text. Is a TLS method required, or simply > suggested? [KH] OK. See Section 4.2.1, i.e. TLS is required. >=20 > 4.2.1. TLS Requirements >=20 > The tunnel based method MUST support TLS version 1.2 [RFC5246] and > may support earlier versions to enable the possibility of backwards > compatibility. The following section discusses=20 > requirements for TLS > Tunnel Establishment. >=20 > Suggest deleting the last sentence. It's a repeat of the sentence > starting off Section 4.2. [KH] OK >=20 > All versions of TLS meet these requirements as long as the cipher > suites used provide strong authentication, key=20 > establishment and data > integrity protection. >=20 > Are we making a statement here that TLS is OK? If the document is a > tunnel requirements document only, it may be prudent to avoid making > statements about which protocols meet the requirements. [KH] TLS is the tunnel protocol that MUST be used by all EAP tunnel-based method candidates.... >=20 >=20 > 4.2.1.1.3. Tunnel Authentication and Key Establishment >=20 > A tunnel method MUST provide unidirectional authentication from > authentication server to EAP peer and mutual authentication between > authentication server and EAP peer. >=20 > How do these requirements interact with requirements in=20 > Section 3.5 for > anonymous network access? Do we want to say that the tunneled method > SHOULD provide for a standardized "anonymous" user and server? [KH] Anonymous server authentication is prohibited. Anonymous peer authentication is OK in the tunnel as long as the peer later authenticates inside the tunnel. I don't see any conflicts here...... >=20 > ... The tunnel method MUST provide > at least one mandatory to implement cipher suite that provides > certificate-based authentication of the server and=20 > provides optional > certificate-based authentication of the client. Other types of > authentication MAY be supported. >=20 > Does this requirement for certificate-based authentication apply > *only* when TLS methods are used? Or is it a wider=20 > requirement that the > tunneled method MUST support TLS and certificate-based methods? [KH] It MUST be a TLS tunnel. >=20 > This requirement should be clarified. >=20 > 4.2.1.2. Tunnel Replay Protection >=20 > In order to prevent replay attacks on a tunnel protocol,=20 > the message > authentication MUST be generated using a time-variant input such as > timestamps, sequence numbers, nonces, or a combination of these so > that any re-use of the authentication data can be detected as > invalid. TLS makes use of an 8 byte sequence number to protect > against replay. >=20 > I'm not sure what is the purpose of the last sentence. An=20 > example of > how to meet the requirements? Something else? >=20 > It may be simplest to just delete the last sentence. >=20 > 4.2.1.4. Peer Identity Privacy >=20 > Is this section necessary? Section 3.4 already mandates identity > protection. I suggest moving this text into Section 3.4, or=20 > rephrasing > it so that it does not overlap with Section 3.4. >=20 >=20 > 4.2.1.5. Session Resumption >=20 > The tunnel method MUST support TLS session resumption as defined in > [RFC5246]. >=20 > ... if we choose a TLS-based method. If we don't, must it still > support TLS session resumption? [KH] Currently the draft requires a TLS-bases method! >=20 > This comment is just being nit-picky to ensure that particular > solutions are not mandated by being written into the=20 > requirements document. >=20 > 4.2.3. Protection of Data External to Tunnel >=20 > An attacker in the middle >=20 > ... of what? Suggest rephrasing like: >=20 > A MitM attack can modify ... [KH] OK. >=20 >=20 > 4.3.3. Mandatory and Optional Attributes >=20 > The payload MUST support marking of mandatory and optional > attributes, as well as an attribute used for rejecting mandatory > attributes. Mandatory attributes are attributes sent by the > requester that the responder is expected to understand and MUST > respond to. >=20 > Given the uncertainty in Diameter about the meaning of "mandatory" > attributes, it would be good to be extremely clear in this document. > This document should specify the behavior carefully. e.g. "Requestor" > and "responder". Does that mean only the peer can mark attributes as > mandatory, and the authenticator cannot? >=20 > The next sentence references a "NAK attribute", without previously > defining it. The previous discussion uses the NAK attribute to reject > mandatory attributes. If the attributes are mandatory, why are they > being rejected? If a responder MUST respond to a mandatory attribute, > is the response marked mandatory, too? What kind of response=20 > is adequate? >=20 > While I can guess the intent, it may be better to rephrase=20 > the discussion. >=20 > Suggested text: >=20 > 4.3.3. Mandatory and Optional Attributes >=20 > The payload MUST support marking of mandatory and optional > attributes, as well as a "NAK" attribute used to communicate > disagreements about received attributes. >=20 > Mandatory attributes are attributes that a receiver MUST process as > per the specification. Optional attributes are attributes that a > receiver MAY ignore. >=20 > A receiver MUST process mandatory attributes before optional ones. > After an attribute has been processed, it SHOULD be marked as no > longer being mandatory. If a receiver does not process a mandatory > attribute, it MUST ignore everything else in a request, and it MUST > send a NAK attribute in response. Similarly, if a receiver expects > a mandatory attribute and does not receive one in a=20 > request, it MUST > send a NAK attribute in the response that contains the set of > attributes it expected to receive. >=20 > A peer that either sends or receives a NAK attribute MUST treat > the session as failing authentication. >=20 > The NAK attribute MUST support a description of which mandatory > attribute is either required, or is not supported. The=20 > NAK attribute > MUST be otherwise treated as an optional attribute, and it MUST NOT > contain a NAK of the NAK attribute, in order to prevent infinite > recursion. >=20 > ... > 4.3.4. Vendor Specific Support >=20 > The payload MUST support communication of an extensible set of > vendor-specific attributes. These attributes will be=20 > segmented into > uniquely identified vendor specific name spaces. They can be used > for experiments or vendor specific features. >=20 > I would suggest adding that vendor-specific attributes SHOULD NOT be > marked as being mandatory. Or maybe even MUST NOT be marked=20 > as mandatory. >=20 > 4.3.6. Internationalization of Display Strings >=20 > The payload MAY provide a standard attribute format that supports > international strings. >=20 > I would suggest changing the MAY to a SHOULD. Not having=20 > displayable > strings is a problem of great vexation to many administrators. >=20 > 4.4. EAP Channel Binding Requirements >=20 > The tunnel method MUST be capable of meeting EAP channel binding > requirements described in [I-D.clancy-emu-chbind]. >=20 > Having a normative reference to an I-D is problematic. I'm not sure > that there is any way of avoiding this, however. >=20 > 4.5.1. Security >=20 > Many internal EAP methods have the peer send its password in the > clear To the EAP server. >=20 > s/To/to/ [KH] OK >=20 > 4.5.1.2. Authentication of Server >=20 > The EAP server MUST be authenticated before the peer can send the > clear text password to the server. >=20 > Suggest replacing "can send" with "sends". [KH] OK >=20 > 4.5.1.3. Server Certificate Revocation Checking >=20 > Does this section apply only when TLS && certificate=20 > methods are used, > or for any method, even non-TLS, and non-certificate? (Just to be > nit-picky again) >=20 > 4.6. Requirements Associated with Carrying EAP Methods >=20 > The tunnel method MUST be able to carry inner EAP methods without > modifying them. EAP methods MUST NOT be redefined inside=20 > the tunnel. >=20 > I would like clarification on the last sentence. Perhaps rephrasing > it as a requirement would be good: >=20 > EAP methods carried inside of the tunnel MUST be identical=20 > in nearly > all respects to the same method when carried outside of the tunnel. > The only permissible difference is that random nonces in a tunneled > method SHOULD be calculated instead by cryptographic methods which > bind the inner method to the outer tunnel. [KH] I don't understand the last sentence. The cryptographic binding is computed by the tunnel-based EAP method not by the inner method. So calculating cryptographic bindings should not require modifications to an inner method. >=20 > 4.6.1. Method Negotiation >=20 > The tunnel method MUST support the protected negotiation=20 > of the inner > EAP method. It MUST NOT allow the inner EAP method=20 > negotiation to be > downgraded or manipulated by intermediaries. >=20 > What is the definition of a "downgraded" EAP method? Perhaps just > deleting that word, and leaving it as "manipulated by" would be best. [KH] I guess manipulated covers downgrading. >=20 > 4.6.3. Cryptographic Binding with the TLS Tunnel >=20 > While this section is already a bit long, I think it could use > additional clarification. It is specifying key derivation functions, > and as such, holds the possibility for interoperability issues. >=20 > ... In > particular, all derived keys MUST have a lifetime assigned=20 > that does > not exceed the lifetime of any key higher in the key hierarchy, and > MUST prevent domino effects where a compromise in one part of the > system leads to compromises in other parts of the system. >=20 > This is the first mention of "lifetime". Should we state that there > is a requirement to exchange key lifetimes, too? >=20 > The MUST comment could also be specified in a positive sense: >=20 > ... In > particular, all derived keys MUST have a lifetime is strictly less > than the lifetime of any key higher in the key hierarchy, [KH] OK >=20 > I'm also unsure as to how to prevent domino effects. Is=20 > the previous > discussion on CTK_n enough of a specification to prevent=20 > domino effects? > If not, should the definitions of CTK_n be extended? If so, is the > following phrase necessary: >=20 > ... and > MUST prevent domino effects where a compromise in one part of the > system leads to compromises in other parts of the system. [KH] May be change to "the compromise of a key in the key hierarchy should not affect any keys higher or at the same level in the key hierarchy." Need to look into this... >=20 > ... >=20 > 6.1. Cipher Suite Selection >=20 > TLS supports ... > ... Since a tunnel method uses the TLS tunnel to transport > data, ... >=20 > Again, are we mandating TLS? If so, this should be=20 > clarified earlier > in the document. [KH] Yes we are...and I guess this has not been clear enough ;) >=20 > 6.4. Separation of TLS Tunnel and Inner Authentication Termination > ... > ... This > may not meet the security policy of many environments." >=20 > There is a stray " in the document. [KH] good catch. >=20 > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >=20