From internet-drafts@ietf.org Tue Jan 3 10:37:33 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FCE21F8489; Tue, 3 Jan 2012 10:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xl5TtAcWtT9z; Tue, 3 Jan 2012 10:37:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DCD21F8483; Tue, 3 Jan 2012 10:37:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120103183732.10803.7483.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 10:37:32 -0800 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-chbind-12.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 18:37:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of th= e IETF. Title : Channel Binding Support for EAP Methods Author(s) : Sam Hartman T. Charles Clancy Katrin Hoeper Filename : draft-ietf-emu-chbind-12.txt Pages : 31 Date : 2012-01-03 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-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-emu-chbind-12.txt From hartmans@mit.edu Tue Jan 3 10:43:49 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77435E8013 for ; Tue, 3 Jan 2012 10:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.132 X-Spam-Level: X-Spam-Status: No, score=-103.132 tagged_above=-999 required=5 tests=[AWL=-3.467, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXVNVJeTNx32 for ; Tue, 3 Jan 2012 10:43:49 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 212195E8012 for ; Tue, 3 Jan 2012 10:43:49 -0800 (PST) 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 F2D1C203C0 for ; Tue, 3 Jan 2012 13:43:14 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DD40E448C; Tue, 3 Jan 2012 13:43:11 -0500 (EST) From: Sam Hartman To: emu@ietf.org References: <20120103183732.10803.7483.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 13:43:11 -0500 In-Reply-To: <20120103183732.10803.7483.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Tue, 03 Jan 2012 10:37:32 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Emu] I-D Action: draft-ietf-emu-chbind-12.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 18:43:49 -0000 The chairs asked me to prepare a new version with the following changes: 1) collapse the registrations in the lower layer type registry as requested by Sean. 2) Add a paragraph to the beginning of Appendix A. I believe I've made these changes. If folks are happy with these two minor changes I think we're ready to send this to the IESG. From internet-drafts@ietf.org Tue Jan 10 10:07:30 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF6121F87DA; Tue, 10 Jan 2012 10:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+lBbFX0UPAx; Tue, 10 Jan 2012 10:07:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061B221F8762; Tue, 10 Jan 2012 10:07:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120110180712.20281.3743.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2012 10:07:12 -0800 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-chbind-13.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:07:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of th= e IETF. Title : Channel Binding Support for EAP Methods Author(s) : Sam Hartman T. Charles Clancy Katrin Hoeper Filename : draft-ietf-emu-chbind-13.txt Pages : 31 Date : 2012-01-10 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-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-emu-chbind-13.txt From hartmans@mit.edu Tue Jan 10 14:41:23 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB9821F882B for ; Tue, 10 Jan 2012 14:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.565 X-Spam-Level: X-Spam-Status: No, score=-103.565 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVeMQ0boARGy for ; Tue, 10 Jan 2012 14:41:23 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 38A6D21F8828 for ; Tue, 10 Jan 2012 14:41:23 -0800 (PST) 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 0384E201C9 for ; Tue, 10 Jan 2012 17:40:49 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 948574974; Tue, 10 Jan 2012 17:40:43 -0500 (EST) From: Sam Hartman To: emu@ietf.org References: <20120110180712.20281.3743.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2012 17:40:43 -0500 In-Reply-To: <20120110180712.20281.3743.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Tue, 10 Jan 2012 10:07:12 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Emu] I-D Action: draft-ietf-emu-chbind-13.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 22:41:23 -0000 Hi, folks, at the chairs request I made a couple of changes 1) Replaced MUST not with MUST NOT in one instance 2) Added a reference to Bernard's radext-wlan draft. There was already textual reference, but not an xref tag. While doing that I noticed that there was a missing against in the sesentence where I fixed the MUST noNOT, so now we MUST not send attributes back where we failed to validate *against* what the peer sends. From jsalowey@cisco.com Tue Jan 10 21:30:29 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2193121F8483; Tue, 10 Jan 2012 21:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3V48wbywnhxj; Tue, 10 Jan 2012 21:30:28 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5DA21F847B; Tue, 10 Jan 2012 21:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=6375; q=dns/txt; s=iport; t=1326259827; x=1327469427; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=fNX+if2Z5AbRRbvC6Hwcrr/JLDP7Ns+9K0UJWHRpO7g=; b=ABvnHLAmavr3jjRVz1S8UdAb1Y0xSYOtHNodiNFsx0E/z9D+y5LA3NWz vG7lHQqt2rJ4qpbGiE5fRg3Y2keLf9J8Bpxy8pEjRn+1ZVa48N1zn9n0O IhkeRswlKZQ3+UfRwwyYELBute/RAF/TWf1qdZAkySBVe0addedJh+PvQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABUdDU+rRDoH/2dsb2JhbABDrFuBBYILAScxDoE+ASYOh2CYUgGeEIs6YwSIOoxShVGNCg X-IronPort-AV: E=Sophos;i="4.71,492,1320624000"; d="scan'208";a="23080778" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 11 Jan 2012 05:30:26 +0000 Received: from [10.33.251.93] ([10.33.251.93]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0B5UPFm001856; Wed, 11 Jan 2012 05:30:26 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jan 2012 21:30:49 -0800 Message-Id: <667A5F4D-8309-4F5C-9B5E-E1AF95D4EC01@cisco.com> To: "Sean P. Turner" , iesg-secretary@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: emu@ietf.org Subject: [Emu] Request to publish draft-ietf-emu-chbind-13.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 05:30:29 -0000 Please publish draft-ietf-emu-chbind-13.txt as an Proposed Standard RFC. = The Proto write-up is included below. =20 Thanks, Joe (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 Joe Salowey, EMU working group co-chair, is the Working Group Shepherd = for this document. The shepherd has reviewed the current version and = believes it is ready for publication. (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed? =20 The document has had review from both key Working Group and Non-working = group members. This includes members of the ABFAB community which = relies upon this document. (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 No (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20 has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 The document shepherd does not have concerns with the document and = believes the document is needed. There has been no IPR disclosure = related to the document.=20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? =20 The document has strong consensus within the working group. However, = there is an individual who is not happy with the document, but has not = posted comments on the latest revisions to the list. The working group = and chairs feel it is appropriate to send the document to the IESG so = additional comments can be made in IETF Last Call.=20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.)=20 No one has threatened an appeal. See previous section. =20 (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the=20 Internet-Drafts Checklist and=20 http://tools.ietf.org/tools/idnits/ ). Boilerplate checks are=20 not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 The document passes ID-nits. There are a few reference issues that can = be resolved in the editing process. =20 (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 The references are complete. (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation?=20 The IANA considerations section is complete.=20 (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 Not applicable. (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=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. Working Group Summary=20 This document has had extensive review in the EMU working group. = =20 The document has clear applicability in ABFAB and Network Access = use cases. =20 Document Quality=20 Project Moonshot, an ABFAB implementation, is working on an = implementation of this document.=20= From violeta.cakulev@alcatel-lucent.com Wed Jan 11 12:16:22 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FA211E80AB for ; Wed, 11 Jan 2012 12:16:22 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFy2sA9rM5dZ for ; Wed, 11 Jan 2012 12:16:21 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7295311E808C for ; Wed, 11 Jan 2012 12:16:21 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q0BKGIBq018371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Jan 2012 14:16:18 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0BKGISs015861 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 11 Jan 2012 14:16:18 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 11 Jan 2012 14:16:18 -0600 From: "Cakulev, Violeta (Violeta)" To: "emu@ietf.org" Date: Wed, 11 Jan 2012 14:16:15 -0600 Thread-Topic: draft-cakulev-emu-eap-ibake Thread-Index: AczQnd7uIoNwwE8jSwSe4FsNQxnKig== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [Emu] draft-cakulev-emu-eap-ibake X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:16:22 -0000 All, Back in IETF 80 we presented EAP-IBAKE. The link to the I-D is provided bel= ow: http://tools.ietf.org/html/draft-cakulev-emu-eap-ibake-01 This EAP method is based on the Identity-Based Authenticated Key Exchange = (IBAKE) protocol. IBAKE is a protocol for mutual authentication and key ag= reement between two or more endpoints. It is based on a public-key based au= thentication mechanism, where each message is encrypted with the public key= of the corresponding endpoint, as per the Identity Based Encryption (IBE)= principles. As a result of the IBAKE protocol, a shared symmetric key is = generated by each endpoint. EAP-IBAKE is specified in ETSI TS 102 690 (stage 2) and ETSI TS 102 921 (st= age 3) as a method for access network independent device and gateway bootst= rapping. Both specifications are approved and are awaiting publication of EAP-IBAKE = (among other things). While this document could be of interest to emu WG, it would probably requi= re changes to the WG charter. Group's opinion about specifying EAP-IBAKE in emu WG as well as possible ch= anges to the WG charter is highly appreciated. Thanks, -Violeta From hartmans@mit.edu Wed Jan 11 12:34:18 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F212B11E80C7 for ; Wed, 11 Jan 2012 12:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.305 X-Spam-Level: X-Spam-Status: No, score=-103.305 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSFMS9Jfwh8c for ; Wed, 11 Jan 2012 12:34:17 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C7E0721F854A for ; Wed, 11 Jan 2012 12:34:16 -0800 (PST) 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 618A4203BA; Wed, 11 Jan 2012 15:33:41 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BCA424974; Wed, 11 Jan 2012 15:33:35 -0500 (EST) From: Sam Hartman To: emu@ietf.org Date: Wed, 11 Jan 2012 15:33:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-emu-chbind@tools.ietf.org, mrw@painless-security.com Subject: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:34:18 -0000 I'd like to thank Margaret Wasserman for coming up with a series of proposed attacks that lead to the following comments. In the context of implementing channel binding and a system that takes advantage of it, I've been focusing on MITM attacks. I'd like to give a example of the sorts of attacks that are worrying me. I thought these were supposed to be solved by crypto binding, but I no longer think that existing implementation of crypto binding are strong enough. First, in a channel binding world, some NASes are significantly more trusted than others. In my ABFAB world that's especially true. We have clients using EAP-TTLS as a tunnel method with some inner password method (MSCHAPv2, some PAKE method, whatever. We'll assume that it generates a key.) We're adding support the EAP-TTLS for channel binding. That's realistic and is consistent with the approach we've been trying to standardize. We want the tunnel methods to support channel binding and perform the channel binding exchange there so we don't have to modify all EAP methods. NEA needs something similar for data they plan to transport over EAP. Consider a compromised print server. It would like to impersonate someone's bank. (In an ABFAb world, EAP is used for things other than network access. I can construct a network access version of this attack if you'd like too.) The print server impersonates the bank enough to get the client to connect to it. It then starts authentication. We're using ABFAB to authenticate the client to the server and the server to the client. The user indicates their home realm in an identity response. The print server, like the bank is a valid participant in the AAA fabric. So it sends an access-request to the home EAP server and gets a method request. In this attack the home EAP server uses TTLS. However the print server wants to MITM the TTLS tunnel. So, while the print server sends the first TTLS packet towards the client, it sends a EAP NACK towards the home EAP server requesting the appropriate inner password method. So, we start to establish a EAP tunnel between the client and the print server and an inner method between the client and the home EAP server. Things will fail if the client validates the tunnel certificate. However if the client goes forward, then the authentication will succeed at the inner method level. Then, assuming we're using TTLSv1, the client will do crypto binding. Intuitively you'd kind of think that crypto binding would help here; I'll discuss in a bit whether it's supposed to. It's quite clear it doesn't though. Crypto binding uses the MSK of the inner method for the binding. However, as part of the access-accept, the home EAP server discloses the MSK to the print server. So, the print server has the material it needs to perform crypto binding and the generate the final MSK. Then the client performs channel binding to confirm that it's talking to the bank. The print server is happy to tell the client that the print server is in fact a bank, so the attack succeeds. For the most part, this is a classic compound authentication attack. If the inner method had not been offered outside the tunnel, the attack generally would not be possible. If different credentials are used, when the method is used inside a tunnel vs outside the attack is not possible. As stated earlier, this particular instance of the attack is not possible if the client verifies the TTLS certificate. There are also ABFAB-specific mitigations that do not generally apply to network access. However, the client does have a secure connection to the home EAP server. Intuitively, we do not actually need to require checking the certificate to provide security against this. If the credential is weak and can be attacked with a passive dictionary attack, then other attacks may be possible if the client does not check the certificate. However if we're using a good PAKE method as an inner method and only using the tunnel for carrying tunneled attributes such as channel binding, there's absolutely no reason the security of the system needs to depend on that certificate check. Whether we like it or not, there are a lot of clients out there that have weak validation of certificates for EAP tunnel methods. Intuitively, crypto binding is supposed to solve MITM attacks with compound authentication. Certainly as I've discussed this issue with some folks in the EAP community they've started out thinking that crypto binding was supposed to solve this sort of thing. Let's go back to RFC 3748 and see what we actually specified for crypto binding though: Cryptographic binding The demonstration of the EAP peer to the EAP server that a single entity has acted as the EAP peer for all methods executed within a tunnel method. Binding MAY also imply that the EAP server demonstrates to the peer that a single entity has acted as the EAP server for all methods executed within a tunnel method. If executed correctly, binding serves to mitigate man-in-the-middle vulnerabilities. So, from that definition it's clear that cryptographic binding doesn't always provide a solution. In particular, this attack is concerned with situations where multiple servers are involved (and should not be) rather than situations where multiple clients are involved. Proving to the client only one server is involved is an optional facility in cryptographic binding. Still, it looks that even in the time of RFC 3748 like people thought that there are cases where we'd want to prove to a client that there was no MITM server. It seems like if that optional facility is provided then we ought to avoid this attack. It's unfortunate that RFC 3748 doesn't name the optional facility where cryptographic binding provides defense against MITM servers. I'll call that mutual cryptographic binding. I'd like to step away from EAP-TTLS and focus on draft-ietf-emu-eap-tunnel-method. If we're going to fix something or document security considerations, let's do it for things we're standardizing first. I'm left with a number of questions: 1) Is mutual cryptographic binding important? 2) What do the tunnel method requirements say about this? 3) Does the tunnel method document intend to provide mutual cryptographic binding? Does it succeed? Should it? 4) What protocol changes should we make? 5) What security considerations should we document? Sot Discussion: 1) Is mutual cryptographic binding important? So, we're starting to do a lot of new things with tunnels and EAP. We're exchanging channel bindings. We're exchanging NEA information. And we're defining extensible tunnel methods where it seems likely that people will propose adding new facilities. In today's EAP for network access situations, the client doesn't actually get much out of the authentication. A lot of the value of EAP is proving the identity of the peer to the EAP server and indirectly the NAS. However, channel bindings, some NEA deployments and other potential uses of EAP increase the importance of the exchange to clients. That is, there's a lot more value in a NAS attacking a client in the future than there is today. Channel bindings are of particular note in this regard because they allow clients to distinguish NASes. At the same time we're talking about standardizing anonymous provisioning (Dan's comments) and otherwise doing things that create cases where we don't expect clients to validate tunnel certificates. We're also doing things that makes certificate validation easier in some cases. But even if we want to ignore deployments where people simply don't validate certificates today, that doesn't completely make this issue go away. This is consistent with use case 3.9 in the tunnel method requirements draft. Let's also think for a moment about peer-side certificate validation. It's not actually enough to simply validate that a certificate is is traced back to a trust anchor. It's actually critical to validate the name of the certificate (or validate a fingerprint). I think it's quite common for peers to be deployed in a configuration that does not check that the presented certificate is linked to a single known and trusted EAP server. So, I think clients that do not validate certificates are quite real. For these reasons, I think this issue will be of increasing importance in the future. Discussion: 2) What do the tunnel method requirements say about this? If you take a look at the bottom of page 6 in tunnel method requirements, there is a discussion of MITM attacks. From that discussion, it sounds like cryptographic binding is believed to be an adequate defense against tunnel MITM attacks for sufficiently strong inner methods. The actual requirement for cryptographic binding is defined in section 4.6.3. That section goes into a lot of detail about how to implement cryptographic binding, but doesn't address the question of who is expected to be able to verify the cryptographic binding or what keys are involved. However reading that section again it sounds like the EAP tunnel method is intended to support cryptographic binding adequate to provide defense against tunnel MITM attacks. It's still kind of ambiguous what was intended. Certainly, section 3.9 implies that the tunnel method needs to be secure when for example the tunnel method is used to add channel binding to an otherwise secure inner EAP method even when server certificates are not validated. Discussion: 3) Does the tunnel method document intend to provide mutual cryptographic binding? Does it succeed? Should it? Take a look at section 4.9.2 and 5.3 in draft-ietf-emu-eap-tunnel-method for the cryptographic binding in the current draft. That section seems to be trying to authenticate the server to the client. There is a copy of the server's compound MAC that is sent to the client. Unfortunately, though, the MAC is protected by a combination of MSKs and the phase 1 keying information according to section 5.3. So, the tunnel method is vulnerable to this class of attack. do we want to fix it? I think so. There's one catch. It gets in the way of terminating the tunnel at a different endpoint than the inner EAP method. Supporting that does not seem to be a requirement. I cannot find any use cases in section 3 of the tunnel method requirements document that requires support for termination. Section 6.4 of the tunnel method requirements discusses the security problems that can result with such termination and hints but does not require that clients be able to determine whether termination at different endpoints has happened. So, I think tunnel termination at different endpoints than the inner method is at best second-class. I'd prefer to start from the assumption that it is not requirement. If the WG gets a consensus that it is a requirement, then I'd prefer to adopt a solution to these MITM issues that prohibits termination at different endpoints by default (in favor of stronger security) but that allows a permissive client to accept no cryptographic binding of servers in appropriately limited circumstances. I'll note that a lot of use cases such as channel binding where the tunnel method is considered without certificate verification are entirely inappropriate if the inner method is terminated at a different place than the tunnel method. Discussion: 4) technical changes The easiest fix seems to be to use the EMSK rather than the MSK to produce the key for the compound MAC. We may want to consider using the EMSK to enfluence both the MSK and EMSK for the overall EAP tunnel method. I believe that if the key is not known to the attacker the construction in section 4.9.2 and 5.3 provides mutual cryptographic binding. I believe that the EMSK of the inner method should not be known to the attacker because the EMSK is not disclosed beyond the EAP server. Discussion: 5) Security Considerations I think we should actually clearly document the difference between mutual cryptographic binding and cryptographic binding. I think we should discuss cases where the mutual cryptographic binding is important--namely cases where the client trusts the tunnel especially when it does not otherwise validate the tunnel. If there are cases where we provide cryptographic binding but not mutual cryptographic binding, we should carefully discuss the risks. Acknowledgements I'd like to thank Margaret Wasserman and Jari Arkko for help in reviewing my analysis. I'd especially like to thank Margaret for finding several attack situations in this space. --Sam From hannes.tschofenig@nsn.com Wed Jan 11 23:07:44 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E44B21F84FB for ; Wed, 11 Jan 2012 23:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.419 X-Spam-Level: X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeZmXt-csiJQ for ; Wed, 11 Jan 2012 23:07:43 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED0421F84F4 for ; Wed, 11 Jan 2012 23:07:43 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q0C77dOg007233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2012 08:07:39 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q0C77cto006203; Thu, 12 Jan 2012 08:07:39 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 08:07:38 +0100 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, 12 Jan 2012 09:07:40 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DFB4C4E@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] draft-cakulev-emu-eap-ibake thread-index: AczQnd7uIoNwwE8jSwSe4FsNQxnKigAWuagg References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Cakulev, Violeta (Violeta)" , X-OriginalArrivalTime: 12 Jan 2012 07:07:38.0681 (UTC) FILETIME=[DE4AC290:01CCD0F8] Subject: Re: [Emu] draft-cakulev-emu-eap-ibake X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 07:07:44 -0000 Hi Violeta,=20 What problem are you trying to solve with this EAP method?=20 Ciao Hannes > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > ext Cakulev, Violeta (Violeta) > Sent: Wednesday, January 11, 2012 10:16 PM > To: emu@ietf.org > Subject: [Emu] draft-cakulev-emu-eap-ibake >=20 > All, > Back in IETF 80 we presented EAP-IBAKE. The link to the I-D is provided > below: > http://tools.ietf.org/html/draft-cakulev-emu-eap-ibake-01 >=20 > This EAP method is based on the Identity-Based Authenticated Key > Exchange (IBAKE) protocol. IBAKE is a protocol for mutual > authentication and key agreement between two or more endpoints. It is > based on a public-key based authentication mechanism, where each > message is encrypted with the public key of the corresponding endpoint, > as per the Identity Based Encryption (IBE) principles. As a result of > the IBAKE protocol, a shared symmetric key is generated by each > endpoint. >=20 > EAP-IBAKE is specified in ETSI TS 102 690 (stage 2) and ETSI TS 102 921 > (stage 3) as a method for access network independent device and gateway > bootstrapping. > Both specifications are approved and are awaiting publication of EAP- > IBAKE (among other things). >=20 > While this document could be of interest to emu WG, it would probably > require changes to the WG charter. >=20 > Group's opinion about specifying EAP-IBAKE in emu WG as well as > possible changes to the WG charter is highly appreciated. >=20 > Thanks, > -Violeta > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From aland@deployingradius.com Thu Jan 12 02:47:50 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514F121F85A7 for ; Thu, 12 Jan 2012 02:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.291 X-Spam-Level: X-Spam-Status: No, score=-102.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg8hwvsB3xit for ; Thu, 12 Jan 2012 02:47:49 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 35C5B21F85A5 for ; Thu, 12 Jan 2012 02:47:49 -0800 (PST) Message-ID: <4F0EBA3A.4040300@deployingradius.com> Date: Thu, 12 Jan 2012 11:47:22 +0100 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: mrw@painless-security.com, draft-ietf-emu-chbind@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 10:47:50 -0000 Sam Hartman wrote: > Then, assuming we're using TTLSv1, the client will do crypto > binding. Intuitively you'd kind of think that crypto binding would help > here; I'll discuss in a bit whether it's supposed to. It's quite clear > it doesn't though. Crypto binding uses the MSK of the inner method for > the binding. RFC 5281 (TTLS) says: Keying material for the subsequent data connection between client and access point (Master Session Key / Extended Master Session Key (MSK/EMSK); see Section 8) is generated based on secret information developed during the TLS handshake between client and TTLS server. > However, as part of the access-accept, the home EAP server > discloses the MSK to the print server. So, the print server has the > material it needs to perform crypto binding and the generate the final > MSK. I don't see how. The print server MUST use the MSK from it's TLS session for crypto bindings. The MSK (if any) received from the home server isn't used for anything. On top of that, the client will verify that any random data (challenges, etc.) are generated from the MSK derived from the TLS session: When a challenge-based authentication mechanism is used, both client and TTLS server use the pseudo-random function to generate as many octets as are required for the challenge, using the constant string "ttls challenge", based on the master secret and random values established during the handshake: If the inner EAP session is forwarded to a home server, it will generate random challenges for methods like CHAP, MS-CHAP, EAP-MD5 and EAP-MSCHAPv1. The client will check the challenges against the data it derives from the PRF. The data will be different, and the client MUST discard it as being invalid. > ... So, I think clients that do not validate > certificates are quite real. Yes. This also includes clients which validate the certificate based on user input. The users are known to just "click through" any certificate warnings. > ... However reading that section again it sounds > like the EAP tunnel method is intended to support cryptographic binding > adequate to provide defense against tunnel MITM attacks. Yes. > Unfortunately, though, the MAC is protected by a combination of MSKs and > the phase 1 keying information according to section 5.3. > So, the tunnel method is vulnerable to this class of attack. I disagree, due to the discussion above. This attack is possible only if the keys are derived from the inner tunnel data, instead of the outer TLS session. Both TTLS and the expired PEAP draft require the MSK to be derived from the outer TLS session. So I find it hard to see how this attack applies. > So, I think tunnel termination at different endpoints than the inner > method is at best second-class. I'd prefer to start from the assumption > that it is not requirement. I agree. > I'll note that a lot of use cases such as channel binding where the > tunnel method is considered without certificate verification are > entirely inappropriate if the inner method is terminated at a different > place than the tunnel method. I'll have a separate response on this topic. Alan DeKok. From aland@deployingradius.com Thu Jan 12 03:21:57 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F4421F85A4 for ; Thu, 12 Jan 2012 03:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.303 X-Spam-Level: X-Spam-Status: No, score=-102.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD28F5DZUxY8 for ; Thu, 12 Jan 2012 03:21:57 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 3698E21F85A1 for ; Thu, 12 Jan 2012 03:21:57 -0800 (PST) Message-ID: <4F0EC23E.1010108@deployingradius.com> Date: Thu, 12 Jan 2012 12:21:34 +0100 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: mrw@painless-security.com, emu@ietf.org Subject: Re: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:21:57 -0000 Sam Hartman wrote: > The print server impersonates the bank enough to get the client to > connect to it. It then starts authentication. We're using ABFAB to > authenticate the client to the server and the server to the client. The > user indicates their home realm in an identity response. > The print server, like the bank is a valid participant in the AAA > fabric. So it sends an access-request to the home EAP server and gets a > method request. As a variant to this attack, if the print server send *NON* EAP requests to the home server, then this will work. The print server will MITM the connection, terminate the TLS tunnel, and do cryptographic bindings. The inner authentication will be handled by the home server, and the client will be unaware. The simplest use-case is PAP. There is no challenge, so crypto bindings don't apply, The next use-case is CHAP. Crypto bindings apply, but most AAA servers will accept *both* the challenge and response in the same request. This means that the MITM server can calculate the challenge using crypto bindings, and send it to the home server. The home server will then authenticate the user. MS-CHAPv1 has the same issue as CHAP. MS-CHAPv2 does not, but it can be trivially converted to MS-CHAPv1. Most AAA servers will accept both v1 and v2. EAP-MD5 and EAP-MSCHAP don't have this issue. But they can be trivially converted to CHAP / MS-CHAPv1. So they have the same issues as CHAP / MS-CHAPv1. So there are many cases where the cryptographic bindings offer *no* guarantee that the server which terminates the TLS tunnel is the same one which authenticates the end user. MITM attacks are not only possible, they are widely deployed. MITM attacks have real-world use cases, where a legacy AAA server is "upgraded" to support EAP, by placing an EAP-aware server in front of it, and applying the protocol conversion outlined above. Alan DeKok. From aland@deployingradius.com Thu Jan 12 03:36:56 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710FA21F85C6 for ; Thu, 12 Jan 2012 03:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.324 X-Spam-Level: X-Spam-Status: No, score=-102.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlhMg9He6ky2 for ; Thu, 12 Jan 2012 03:36:56 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id D321221F85C5 for ; Thu, 12 Jan 2012 03:36:55 -0800 (PST) Message-ID: <4F0EC5BF.20906@deployingradius.com> Date: Thu, 12 Jan 2012 12:36:31 +0100 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: mrw@painless-security.com, emu@ietf.org Subject: Re: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:36:56 -0000 This is the third message in my response to Sam's long post. This topic: channel bindings. Sam Hartman wrote: > I'll note that a lot of use cases such as channel binding where the > tunnel method is considered without certificate verification are > entirely inappropriate if the inner method is terminated at a different > place than the tunnel method. How do we want to solve that problem? The current crypto bindings tie the inner tunnel authentication to the TLS MSK. We can't use the TLS MSK to sign the channel binding data, as a MITM server could just sign it, and never send it to the home server. The only solution I can think of is to tie the channel binding data to the authentication credentials. This could be done by using an HMAC over the channel binding data, using a key derived from the users authentication credentials. The client could then sign the channel binding data using this HMAC. The home server could verify it, and sign its response using the same method. The client would then verify the response. This method still allows MITM attacks, but ensures that the home server has seen the channel binding data. We could also key the HMAC using a key derived from *both* the TLS MSK and from the users authentication credentials. This would ensure that MITM attacks are impossible. I'm interested in seeing a wider discussion of these topics. Alan DeKok. From violeta.cakulev@alcatel-lucent.com Thu Jan 12 07:16:53 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8850A21F8623 for ; Thu, 12 Jan 2012 07:16:53 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsIFYwmTKixN for ; Thu, 12 Jan 2012 07:16:52 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC3421F861D for ; Thu, 12 Jan 2012 07:16:52 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q0CFGnT9005942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2012 09:16:50 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0CFGekp021143 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Jan 2012 09:16:49 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 12 Jan 2012 09:16:46 -0600 From: "Cakulev, Violeta (Violeta)" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "emu@ietf.org" Date: Thu, 12 Jan 2012 09:16:42 -0600 Thread-Topic: [Emu] draft-cakulev-emu-eap-ibake Thread-Index: AczQnd7uIoNwwE8jSwSe4FsNQxnKigAWuaggABD4xNA= Message-ID: References: <999913AB42CC9341B05A99BBF358718DFB4C4E@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DFB4C4E@FIESEXC035.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [Emu] draft-cakulev-emu-eap-ibake X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 15:16:53 -0000 Hannes, Thanks for the interest. IBAKE was proposed and adopted as a method for device bootstrapping in ETSI= M2M. IBAKE is especially suitable in this setting as it is a method that provide= s mutual authentication and key agreement without the need to rely on third= parties such as certificate authorities. So the specific problem that is being solved in ETSI M2M with EAP-IBAKE is = device bootstrapping that is access network independent. Obviously, as an EAP method EAP-IBAKE can address many other problems (as n= umerous other EAP methods can). Regards, -Violeta -----Original Message----- From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com= ] Sent: Thursday, January 12, 2012 2:08 AM To: Cakulev, Violeta (Violeta); emu@ietf.org Subject: RE: [Emu] draft-cakulev-emu-eap-ibake Hi Violeta, What problem are you trying to solve with this EAP method? Ciao Hannes > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > ext Cakulev, Violeta (Violeta) > Sent: Wednesday, January 11, 2012 10:16 PM > To: emu@ietf.org > Subject: [Emu] draft-cakulev-emu-eap-ibake > > All, > Back in IETF 80 we presented EAP-IBAKE. The link to the I-D is provided > below: > http://tools.ietf.org/html/draft-cakulev-emu-eap-ibake-01 > > This EAP method is based on the Identity-Based Authenticated Key > Exchange (IBAKE) protocol. IBAKE is a protocol for mutual > authentication and key agreement between two or more endpoints. It is > based on a public-key based authentication mechanism, where each > message is encrypted with the public key of the corresponding endpoint, > as per the Identity Based Encryption (IBE) principles. As a result of > the IBAKE protocol, a shared symmetric key is generated by each > endpoint. > > EAP-IBAKE is specified in ETSI TS 102 690 (stage 2) and ETSI TS 102 921 > (stage 3) as a method for access network independent device and gateway > bootstrapping. > Both specifications are approved and are awaiting publication of EAP- > IBAKE (among other things). > > While this document could be of interest to emu WG, it would probably > require changes to the WG charter. > > Group's opinion about specifying EAP-IBAKE in emu WG as well as > possible changes to the WG charter is highly appreciated. > > Thanks, > -Violeta > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hannes.tschofenig@nsn.com Thu Jan 12 07:24:22 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BD421F8619 for ; Thu, 12 Jan 2012 07:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.426 X-Spam-Level: X-Spam-Status: No, score=-106.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9u4ImsVBf3Q for ; Thu, 12 Jan 2012 07:24:21 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1EB21F8574 for ; Thu, 12 Jan 2012 07:24:20 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q0CFN9eL019473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2012 16:23:09 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q0CFN8YT019011; Thu, 12 Jan 2012 16:23:08 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 16:23:08 +0100 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, 12 Jan 2012 17:23:07 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DFB50E5@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] draft-cakulev-emu-eap-ibake thread-index: AczQnd7uIoNwwE8jSwSe4FsNQxnKigAWuaggABD4xNAAAClZwA== References: <999913AB42CC9341B05A99BBF358718DFB4C4E@FIESEXC035.nsn-intra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Cakulev, Violeta (Violeta)" , X-OriginalArrivalTime: 12 Jan 2012 15:23:08.0719 (UTC) FILETIME=[16C68BF0:01CCD13E] Subject: Re: [Emu] draft-cakulev-emu-eap-ibake X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 15:24:22 -0000 Hi Violeta,=20 I believe it would be useful to solicit comments from a working group like CORE, who works on this smart object space. In that group folks had come up with their ideas on how to bootstrap security for these types of devices. Of course, it has nothing to-do with identity based cryptography.=20 If you want to hear my personal opinion: I don't think that identity based cryptography solves any real problems.=20 Ciao Hannes > -----Original Message----- > From: ext Cakulev, Violeta (Violeta) [mailto:violeta.cakulev@alcatel- > lucent.com] > Sent: Thursday, January 12, 2012 5:17 PM > To: Tschofenig, Hannes (NSN - FI/Espoo); emu@ietf.org > Subject: RE: [Emu] draft-cakulev-emu-eap-ibake >=20 > Hannes, > Thanks for the interest. >=20 > IBAKE was proposed and adopted as a method for device bootstrapping in > ETSI M2M. > IBAKE is especially suitable in this setting as it is a method that > provides mutual authentication and key agreement without the need to > rely on third parties such as certificate authorities. > So the specific problem that is being solved in ETSI M2M with EAP-IBAKE > is device bootstrapping that is access network independent. >=20 > Obviously, as an EAP method EAP-IBAKE can address many other problems > (as numerous other EAP methods can). >=20 > Regards, > -Violeta >=20 > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: Thursday, January 12, 2012 2:08 AM > To: Cakulev, Violeta (Violeta); emu@ietf.org > Subject: RE: [Emu] draft-cakulev-emu-eap-ibake >=20 > Hi Violeta, >=20 > What problem are you trying to solve with this EAP method? >=20 > Ciao > Hannes >=20 > > -----Original Message----- > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > > ext Cakulev, Violeta (Violeta) > > Sent: Wednesday, January 11, 2012 10:16 PM > > To: emu@ietf.org > > Subject: [Emu] draft-cakulev-emu-eap-ibake > > > > All, > > Back in IETF 80 we presented EAP-IBAKE. The link to the I-D is > provided > > below: > > http://tools.ietf.org/html/draft-cakulev-emu-eap-ibake-01 > > > > This EAP method is based on the Identity-Based Authenticated Key > > Exchange (IBAKE) protocol. IBAKE is a protocol for mutual > > authentication and key agreement between two or more endpoints. It is > > based on a public-key based authentication mechanism, where each > > message is encrypted with the public key of the corresponding > endpoint, > > as per the Identity Based Encryption (IBE) principles. As a result > of > > the IBAKE protocol, a shared symmetric key is generated by each > > endpoint. > > > > EAP-IBAKE is specified in ETSI TS 102 690 (stage 2) and ETSI TS 102 > 921 > > (stage 3) as a method for access network independent device and > gateway > > bootstrapping. > > Both specifications are approved and are awaiting publication of EAP- > > IBAKE (among other things). > > > > While this document could be of interest to emu WG, it would probably > > require changes to the WG charter. > > > > Group's opinion about specifying EAP-IBAKE in emu WG as well as > > possible changes to the WG charter is highly appreciated. > > > > Thanks, > > -Violeta > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Thu Jan 12 07:33:36 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22E621F8578 for ; Thu, 12 Jan 2012 07:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.132 X-Spam-Level: X-Spam-Status: No, score=-103.132 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CVbCVPhMwls for ; Thu, 12 Jan 2012 07:33:36 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF6E21F8577 for ; Thu, 12 Jan 2012 07:33:34 -0800 (PST) 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 A8648203BA; Thu, 12 Jan 2012 10:32:59 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2D9734974; Thu, 12 Jan 2012 10:33:31 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <4F0EBA3A.4040300@deployingradius.com> Date: Thu, 12 Jan 2012 10:33:31 -0500 In-Reply-To: <4F0EBA3A.4040300@deployingradius.com> (Alan DeKok's message of "Thu, 12 Jan 2012 11:47:22 +0100") 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: draft-ietf-emu-chbind@tools.ietf.org, mrw@painless-security.com, Sam Hartman , emu@ietf.org Subject: Re: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 15:33:36 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Sam Hartman wrote: >> Then, assuming we're using TTLSv1, the client will do crypto >> binding. Intuitively you'd kind of think that crypto binding >> would help here; I'll discuss in a bit whether it's supposed >> to. It's quite clear it doesn't though. Crypto binding uses the >> MSK of the inner method for the binding. Alan> RFC 5281 (TTLS) says: Alan> Keying material for the subsequent data connection between Alan> client and access point (Master Session Key / Extended Master Alan> Session Key (MSK/EMSK); see Section 8) is generated based on Alan> secret information developed during the TLS handshake between Alan> client and TTLS server. RFc 5281 does not provide cryptographic binding. >> However, as part of the access-accept, the home EAP server >> discloses the MSK to the print server. So, the print server has >> the material it needs to perform crypto binding and the generate >> the final MSK. Alan> I don't see how. The print server MUST use the MSK from Alan> it's TLS session for crypto bindings. The MSK (if any) Alan> received from the home server isn't used for anything. In RFC 5281 there is no cryptographic binding, so the attack trivially succeeds without using the inner MSK. Alan> On top of that, the client will verify that any random data Alan> (challenges, etc.) are generated from the MSK derived from the Alan> TLS session: Alan> When a challenge-based authentication mechanism is used, Alan> both client and TTLS server use the pseudo-random function to Alan> generate as many octets as are required for the challenge, Alan> using the constant string "ttls challenge", based on the Alan> master secret and random values established during the Alan> handshake: Alan> If the inner EAP session is forwarded to a home server, it Alan> will generate random challenges for methods like CHAP, Alan> MS-CHAP, EAP-MD5 and EAP-MSCHAPv1. The client will check the Alan> challenges against the data it derives from the PRF. The data Alan> will be different, and the client MUST discard it as being Alan> invalid. As I read RFC 5281, the implicit challenge described in section 11.1 is only used if one of the implicit (non-EAP) tunneled authentications is used, as described say in section 11.2.2. However if EAP is used as described in 11.2.1, then the implicit challenge in 11.1 is not used. Using it would be a layering violation. The implicit challenge described in 11.1 in RFc 5281 does not permit the specific attack I described. It inherently permits a different set of MITM attacks though, under which the attacker controls the challenge. >> ... So, I think clients that do not validate certificates are >> quite real. Alan> Yes. This also includes clients which validate the Alan> certificate based on user input. The users are known to just Alan> "click through" any certificate warnings. Right. >> ... However reading that section again it sounds like the EAP >> tunnel method is intended to support cryptographic binding >> adequate to provide defense against tunnel MITM attacks. Alan> Yes. >> Unfortunately, though, the MAC is protected by a combination of >> MSKs and the phase 1 keying information according to section 5.3. >> So, the tunnel method is vulnerable to this class of attack. Alan> I disagree, due to the discussion above. The discussion above is very TTLS specific. My point definitely applies unmodified to draft-ietf-emu-eap-tunnel-method Alan> This attack is possible only if the keys are derived from Alan> the inner tunnel data, instead of the outer TLS session. No. The attacker controls the outer TLS session. The attacker knows the MSK. The keys need to be derived from something the attacker does not know in order to avoid an attack. From violeta.cakulev@alcatel-lucent.com Thu Jan 12 07:57:13 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDDE21F861D for ; Thu, 12 Jan 2012 07:57:13 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uwgtHGpcbWR for ; Thu, 12 Jan 2012 07:57:12 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0385E21F85E6 for ; Thu, 12 Jan 2012 07:57:11 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q0CFvBMx024170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2012 09:57:11 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0CFuY7h021110 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Jan 2012 09:57:06 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Thu, 12 Jan 2012 09:57:02 -0600 From: "Cakulev, Violeta (Violeta)" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "emu@ietf.org" Date: Thu, 12 Jan 2012 09:57:01 -0600 Thread-Topic: [Emu] draft-cakulev-emu-eap-ibake Thread-Index: AczQnd7uIoNwwE8jSwSe4FsNQxnKigAWuaggABD4xNAAAClZwAAA61lA Message-ID: References: <999913AB42CC9341B05A99BBF358718DFB4C4E@FIESEXC035.nsn-intra.net> <999913AB42CC9341B05A99BBF358718DFB50E5@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DFB50E5@FIESEXC035.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [Emu] draft-cakulev-emu-eap-ibake X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 15:57:13 -0000 Hannes, Thanks for the comments/opinions. While soliciting comments from CORE on EAP-IBAKE and bootstrapping in gener= al would be most certainly helpful, ETSI M2M already concluded discussions = on the choice of bootstrapping methods. Both stage 2 (ETSI 102 690) and stage 3 (ETSI 102 921) are frozen and new m= ethods will not be taken into consideration for rel. 1. Given that EAP-IBAKE is a bootstrapping method in these specifications, we = are trying to ensure appropriate review and timely publication of EAP-IBAKE= I-D. Regards, -Violeta -----Original Message----- From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com= ] Sent: Thursday, January 12, 2012 10:23 AM To: Cakulev, Violeta (Violeta); emu@ietf.org Subject: RE: [Emu] draft-cakulev-emu-eap-ibake Hi Violeta, I believe it would be useful to solicit comments from a working group like CORE, who works on this smart object space. In that group folks had come up with their ideas on how to bootstrap security for these types of devices. Of course, it has nothing to-do with identity based cryptography. If you want to hear my personal opinion: I don't think that identity based cryptography solves any real problems. Ciao Hannes > -----Original Message----- > From: ext Cakulev, Violeta (Violeta) [mailto:violeta.cakulev@alcatel- > lucent.com] > Sent: Thursday, January 12, 2012 5:17 PM > To: Tschofenig, Hannes (NSN - FI/Espoo); emu@ietf.org > Subject: RE: [Emu] draft-cakulev-emu-eap-ibake > > Hannes, > Thanks for the interest. > > IBAKE was proposed and adopted as a method for device bootstrapping in > ETSI M2M. > IBAKE is especially suitable in this setting as it is a method that > provides mutual authentication and key agreement without the need to > rely on third parties such as certificate authorities. > So the specific problem that is being solved in ETSI M2M with EAP-IBAKE > is device bootstrapping that is access network independent. > > Obviously, as an EAP method EAP-IBAKE can address many other problems > (as numerous other EAP methods can). > > Regards, > -Violeta > > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: Thursday, January 12, 2012 2:08 AM > To: Cakulev, Violeta (Violeta); emu@ietf.org > Subject: RE: [Emu] draft-cakulev-emu-eap-ibake > > Hi Violeta, > > What problem are you trying to solve with this EAP method? > > Ciao > Hannes > > > -----Original Message----- > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > > ext Cakulev, Violeta (Violeta) > > Sent: Wednesday, January 11, 2012 10:16 PM > > To: emu@ietf.org > > Subject: [Emu] draft-cakulev-emu-eap-ibake > > > > All, > > Back in IETF 80 we presented EAP-IBAKE. The link to the I-D is > provided > > below: > > http://tools.ietf.org/html/draft-cakulev-emu-eap-ibake-01 > > > > This EAP method is based on the Identity-Based Authenticated Key > > Exchange (IBAKE) protocol. IBAKE is a protocol for mutual > > authentication and key agreement between two or more endpoints. It is > > based on a public-key based authentication mechanism, where each > > message is encrypted with the public key of the corresponding > endpoint, > > as per the Identity Based Encryption (IBE) principles. As a result > of > > the IBAKE protocol, a shared symmetric key is generated by each > > endpoint. > > > > EAP-IBAKE is specified in ETSI TS 102 690 (stage 2) and ETSI TS 102 > 921 > > (stage 3) as a method for access network independent device and > gateway > > bootstrapping. > > Both specifications are approved and are awaiting publication of EAP- > > IBAKE (among other things). > > > > While this document could be of interest to emu WG, it would probably > > require changes to the WG charter. > > > > Group's opinion about specifying EAP-IBAKE in emu WG as well as > > possible changes to the WG charter is highly appreciated. > > > > Thanks, > > -Violeta > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu From hannes.tschofenig@gmx.net Thu Jan 12 09:29:49 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9736D21F85AA for ; Thu, 12 Jan 2012 09:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kzny2Gl3kVDp for ; Thu, 12 Jan 2012 09:29:48 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id C0B7721F8596 for ; Thu, 12 Jan 2012 09:29:47 -0800 (PST) Received: (qmail invoked by alias); 12 Jan 2012 17:29:44 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.216.191] by mail.gmx.net (mp068) with SMTP; 12 Jan 2012 18:29:44 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ceX9BB2AcnWTyWOo8DaPs61Z1bARhorzryumB22 9DoEajJ0GjJF8x Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 12 Jan 2012 19:29:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: mrw@painless-security.com, draft-ietf-emu-chbind@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 17:29:49 -0000 Hi Sam,=20 let us start with the problem description: You claim that EAP peer = implementations use PK-based authentication but do not do certificate = validation. This obviously introduces attacks (regardless of channel = bindings, or crypto bindings).=20 Any evidence that this is really a problem? And if it is a problem why = that cannot be fixed with a software update. If you chose a specific EAP = method then you obviously have to deploy the necessary credentials and = parameters at both end points in order for it to work.=20 Ciao Hannes PS: You are sometimes a bit relaxed with your terminology. Whenever you = talk about client and server you need to qualify that further because = there are multiple clients and servers involved in this three party = exchange.=20 On Jan 11, 2012, at 10:33 PM, Sam Hartman wrote: >=20 > I'd like to thank Margaret Wasserman for coming up with a series of > proposed attacks that lead to the following comments. >=20 >=20 > In the context of implementing channel binding and a system that takes > advantage of it, I've been focusing on MITM attacks. I'd like to give = a > example of the sorts of attacks that are worrying me. I thought these > were supposed to be solved by crypto binding, but I no longer think = that > existing implementation of crypto binding are strong enough. >=20 > First, in a channel binding world, some NASes are significantly more > trusted than others. In my ABFAB world that's especially true. >=20 > We have clients using EAP-TTLS as a tunnel method with some inner > password method (MSCHAPv2, some PAKE method, whatever. We'll assume = that > it generates a key.) We're adding support the EAP-TTLS for channel > binding. That's realistic and is consistent with the approach we've = been > trying to standardize. We want the tunnel methods to support channel > binding and perform the channel binding exchange there so we don't = have > to modify all EAP methods. NEA needs something similar for data they > plan to transport over EAP. >=20 > Consider a compromised print server. It would like to impersonate > someone's bank. (In an ABFAb world, EAP is used for things other than > network access. I can construct a network access version of this = attack > if you'd like too.) >=20 > The print server impersonates the bank enough to get the client to > connect to it. It then starts authentication. We're using ABFAB to > authenticate the client to the server and the server to the client. = The > user indicates their home realm in an identity response.=20 > The print server, like the bank is a valid participant in the AAA > fabric. So it sends an access-request to the home EAP server and gets = a > method request. >=20 > In this attack the home EAP server uses TTLS. However the print server > wants to MITM the TTLS tunnel. So, while the print server sends the > first TTLS packet towards the client, it sends a EAP NACK towards the > home EAP server requesting the appropriate inner password method. >=20 > So, we start to establish a EAP tunnel between the client and the = print > server and an inner method between the client and the home EAP server. > Things will fail if the client validates the tunnel certificate. >=20 > However if the client goes forward, then the authentication will > succeed at the inner method level. >=20 > Then, assuming we're using TTLSv1, the client will do crypto > binding. Intuitively you'd kind of think that crypto binding would = help > here; I'll discuss in a bit whether it's supposed to. It's quite clear > it doesn't though. Crypto binding uses the MSK of the inner method for > the binding. However, as part of the access-accept, the home EAP = server > discloses the MSK to the print server. So, the print server has the > material it needs to perform crypto binding and the generate the final > MSK. >=20 > Then the client performs channel binding to confirm that it's talking = to > the bank. The print server is happy to tell the client that the print > server is in fact a bank, so the attack succeeds. >=20 > For the most part, this is a classic compound authentication attack. = If > the inner method had not been offered outside the tunnel, the attack > generally would not be possible. If different credentials are used, = when > the method is used inside a tunnel vs outside the attack is not > possible. As stated earlier, this particular instance of the attack = is > not possible if the client verifies the TTLS certificate. There are = also > ABFAB-specific mitigations that do not generally apply to network > access. >=20 > However, the client does have a secure connection to the home EAP > server. Intuitively, we do not actually need to require checking the > certificate to provide security against this. If the credential is = weak > and can be attacked with a passive dictionary attack, then other = attacks > may be possible if the client does not check the certificate. However = if > we're using a good PAKE method as an inner method and only using the > tunnel for carrying tunneled attributes such as channel binding, = there's > absolutely no reason the security of the system needs to depend on = that > certificate check. Whether we like it or not, there are a lot of = clients > out there that have weak validation of certificates for EAP tunnel > methods. >=20 > Intuitively, crypto binding is supposed to solve MITM attacks with > compound authentication. Certainly as I've discussed this issue with > some folks in the EAP community they've started out thinking that = crypto > binding was supposed to solve this sort of thing. > Let's go back to RFC 3748 and see what we actually specified for = crypto > binding though: >=20 > Cryptographic binding > The demonstration of the EAP peer to the EAP server that a = single > entity has acted as the EAP peer for all methods executed = within a > tunnel method. Binding MAY also imply that the EAP = server > demonstrates to the peer that a single entity = has acted as the EAP > server for all methods executed within = a tunnel method. If > executed correctly, binding = serves to mitigate man-in-the-middle > vulnerabilities. > =20 >=20 > So, from that definition it's clear that cryptographic binding doesn't > always provide a solution. In particular, this attack is concerned = with > situations where multiple servers are involved (and should not be) > rather than situations where multiple clients are involved.=20 > Proving to the client only one server is involved is an optional > facility in cryptographic binding. > Still, it looks that even in the time of RFC 3748 like people thought > that there are cases where we'd want to prove to a client that there = was > no MITM server. > It seems like if that optional facility is provided then we ought to > avoid this attack. >=20 > It's unfortunate that RFC 3748 doesn't name the optional facility = where > cryptographic binding provides defense against MITM servers. I'll call > that mutual cryptographic binding. >=20 > I'd like to step away from EAP-TTLS and focus on > draft-ietf-emu-eap-tunnel-method. If we're going to fix something or > document security considerations, let's do it for things we're > standardizing first. >=20 > I'm left with a number of questions: >=20 > 1) Is mutual cryptographic binding important? >=20 > 2) What do the tunnel method requirements say about this? >=20 > 3) Does the tunnel method document intend to provide mutual > cryptographic binding? Does it succeed? Should it? >=20 > 4) What protocol changes should we make? >=20 > 5) What security considerations should we document? >=20 >=20 > Sot >=20 >=20 > Discussion: 1) Is mutual cryptographic binding important? >=20 > So, we're starting to do a lot of new things with tunnels and EAP. = We're > exchanging channel bindings. We're exchanging NEA information. And = we're > defining extensible tunnel methods where it seems likely that people > will propose adding new facilities. > In today's EAP for network access situations, the client doesn't > actually get much out of the authentication. A lot of the value of EAP > is proving the identity of the peer to the EAP server and indirectly = the > NAS. > However, channel bindings, some NEA deployments and other potential = uses > of EAP increase the importance of the exchange to clients. > That is, there's a lot more value in a NAS attacking a client in the > future than there is today. >=20 > Channel bindings are of particular note in this regard because they > allow clients to distinguish NASes. >=20 > At the same time we're talking about standardizing anonymous > provisioning (Dan's comments) and otherwise doing things that create > cases where we don't expect clients to validate tunnel > certificates. We're also doing things that makes certificate = validation > easier in some cases. But even if we want to ignore deployments where > people simply don't validate certificates today, that doesn't = completely > make this issue go away. This is consistent with use case 3.9 in the > tunnel method requirements draft. >=20 > Let's also think for a moment about peer-side certificate > validation. It's not actually enough to simply validate that a > certificate is is traced back to a trust anchor. It's actually = critical > to validate the name of the certificate (or validate a fingerprint). I > think it's quite common for peers to be deployed in a configuration = that > does not check that the presented certificate is linked to a single > known and trusted EAP server. So, I think clients that do not validate > certificates are quite real. >=20 > For these reasons, I think this issue will be of increasing importance > in the future. >=20 > Discussion: 2) What do the tunnel method requirements say about this? >=20 > If you take a look at the bottom of page 6 in tunnel method > requirements, there is a discussion of MITM attacks. =46rom that > discussion, it sounds like cryptographic binding is believed to be an > adequate defense against tunnel MITM attacks for sufficiently strong > inner methods. The actual requirement for cryptographic binding is > defined in section 4.6.3. That section goes into a lot of detail about > how to implement cryptographic binding, but doesn't address the = question > of who is expected to be able to verify the cryptographic binding or > what keys are involved. However reading that section again it sounds > like the EAP tunnel method is intended to support cryptographic = binding > adequate to provide defense against tunnel MITM attacks. >=20 > It's still kind of ambiguous what was intended. Certainly, section = 3.9 > implies that the tunnel method needs to be secure when for example the > tunnel method is used to add channel binding to an otherwise secure > inner EAP method even when server certificates are not validated. >=20 >=20 >=20 > Discussion: 3) Does the tunnel method document intend to provide = mutual > cryptographic binding? Does it succeed? Should it? >=20 > Take a look at section 4.9.2 and 5.3 in = draft-ietf-emu-eap-tunnel-method > for the cryptographic binding in the current draft. > That section seems to be trying to authenticate the server to the > client. There is a copy of the server's compound MAC that is sent to = the > client. > Unfortunately, though, the MAC is protected by a combination of MSKs = and > the phase 1 keying information according to section 5.3. > So, the tunnel method is vulnerable to this class of attack. >=20 > do we want to fix it? I think so. There's one catch. It gets in the > way of terminating the tunnel at a different endpoint than the inner = EAP > method. Supporting that does not seem to be a requirement. I cannot > find any use cases in section 3 of the tunnel method requirements > document that requires support for termination. Section 6.4 of the > tunnel method requirements discusses the security problems that can > result with such termination and hints but does not require that = clients > be able to determine whether termination at different endpoints has > happened. >=20 > So, I think tunnel termination at different endpoints than the inner > method is at best second-class. I'd prefer to start from the = assumption > that it is not requirement. If the WG gets a consensus that it is a > requirement, then I'd prefer to adopt a solution to these MITM issues > that prohibits termination at different endpoints by default (in favor > of stronger security) but that allows a permissive client to accept no > cryptographic binding of servers in appropriately limited = circumstances. > I'll note that a lot of use cases such as channel binding where the > tunnel method is considered without certificate verification are > entirely inappropriate if the inner method is terminated at a = different > place than the tunnel method. >=20 >=20 > Discussion: 4) technical changes >=20 > The easiest fix seems to be to use the EMSK rather than the MSK to > produce the key for the compound MAC. We may want to consider using = the > EMSK to enfluence both the MSK and EMSK for the overall EAP tunnel > method. I believe that if the key is not known to the attacker the > construction in section 4.9.2 and 5.3 provides mutual cryptographic > binding. I believe that the EMSK of the inner method should not be = known > to the attacker because the EMSK is not disclosed beyond the EAP = server. >=20 > Discussion: 5) Security Considerations >=20 > I think we should actually clearly document the difference between > mutual cryptographic binding and cryptographic binding. > I think we should discuss cases where the mutual cryptographic binding > is important--namely cases where the client trusts the tunnel = especially > when it does not otherwise validate the tunnel. >=20 > If there are cases where we provide cryptographic binding but not = mutual > cryptographic binding, we should carefully discuss the risks. >=20 > Acknowledgements >=20 > I'd like to thank Margaret Wasserman and Jari Arkko for help in > reviewing my analysis. I'd especially like to thank Margaret for = finding > several attack situations in this space. >=20 > --Sam > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hannes.tschofenig@gmx.net Thu Jan 12 09:43:32 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90C121F85BD for ; Thu, 12 Jan 2012 09:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqidZHefctT3 for ; Thu, 12 Jan 2012 09:43:32 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9275021F8631 for ; Thu, 12 Jan 2012 09:43:31 -0800 (PST) Received: (qmail invoked by alias); 12 Jan 2012 17:43:29 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.216.191] by mail.gmx.net (mp066) with SMTP; 12 Jan 2012 18:43:29 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19RipdCVINRspHUbgK1b5JFGG9M5OVRMyki8GjPaf JRUgW63E/Le5SH Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 12 Jan 2012 19:43:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54D56B18-BB76-44BC-B48B-3ED5E7DAE045@gmx.net> References: <999913AB42CC9341B05A99BBF358718DFB4C4E@FIESEXC035.nsn-intra.net> <999913AB42CC9341B05A99BBF358718DFB50E5@FIESEXC035.nsn-intra.net> To: "Cakulev, Violeta (Violeta)" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "emu@ietf.org" Subject: Re: [Emu] draft-cakulev-emu-eap-ibake X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 17:43:33 -0000 Hi Violeta,=20 I am unfortunately familiar with the details of the ETSI = Machine-to-Machine specifications to judge whether your draft meets = their design requirements and fits into their architecture. I am sure = lots of experts in ETSI have looked at this problem and have made a = thoughtful decision. I wish them good luck deploying all their stuff.=20 Having said that I feel that you are likely going into a problem that I = have observed many times in the IETF: folks typically want to understand = the problem they are trying to solve and they tend to be unsatisfied = with the response "ETSI needs it.".=20 Luckily things are looking good for you: If you do not seek publication = of this EAP method as a Standards Track RFC then the process is fairly = simple. In fact, you do not even go through the IETF to get a method ID. = You can just dump the draft text into the appendix of the ETSI = specification, drop IANA a mail, and you are done with it.=20 The story is quite different if you want to get this standardized as a = Standards Track RFC (which is what your draft currently says).=20 Ciao Hannes On Jan 12, 2012, at 5:57 PM, Cakulev, Violeta (Violeta) wrote: > Hannes, > Thanks for the comments/opinions. >=20 > While soliciting comments from CORE on EAP-IBAKE and bootstrapping in = general would be most certainly helpful, ETSI M2M already concluded = discussions on the choice of bootstrapping methods. > Both stage 2 (ETSI 102 690) and stage 3 (ETSI 102 921) are frozen and = new methods will not be taken into consideration for rel. 1. >=20 > Given that EAP-IBAKE is a bootstrapping method in these = specifications, we are trying to ensure appropriate review and timely = publication of EAP-IBAKE I-D. >=20 > Regards, >=20 > -Violeta >=20 > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) = [mailto:hannes.tschofenig@nsn.com] > Sent: Thursday, January 12, 2012 10:23 AM > To: Cakulev, Violeta (Violeta); emu@ietf.org > Subject: RE: [Emu] draft-cakulev-emu-eap-ibake >=20 > Hi Violeta, >=20 > I believe it would be useful to solicit comments from a working group > like CORE, who works on this smart object space. In that group folks = had > come up with their ideas on how to bootstrap security for these types = of > devices. Of course, it has nothing to-do with identity based > cryptography. >=20 > If you want to hear my personal opinion: I don't think that identity > based cryptography solves any real problems. >=20 > Ciao > Hannes >=20 >> -----Original Message----- >> From: ext Cakulev, Violeta (Violeta) [mailto:violeta.cakulev@alcatel- >> lucent.com] >> Sent: Thursday, January 12, 2012 5:17 PM >> To: Tschofenig, Hannes (NSN - FI/Espoo); emu@ietf.org >> Subject: RE: [Emu] draft-cakulev-emu-eap-ibake >>=20 >> Hannes, >> Thanks for the interest. >>=20 >> IBAKE was proposed and adopted as a method for device bootstrapping = in >> ETSI M2M. >> IBAKE is especially suitable in this setting as it is a method that >> provides mutual authentication and key agreement without the need to >> rely on third parties such as certificate authorities. >> So the specific problem that is being solved in ETSI M2M with > EAP-IBAKE >> is device bootstrapping that is access network independent. >>=20 >> Obviously, as an EAP method EAP-IBAKE can address many other problems >> (as numerous other EAP methods can). >>=20 >> Regards, >> -Violeta >>=20 >> -----Original Message----- >> From: Tschofenig, Hannes (NSN - FI/Espoo) >> [mailto:hannes.tschofenig@nsn.com] >> Sent: Thursday, January 12, 2012 2:08 AM >> To: Cakulev, Violeta (Violeta); emu@ietf.org >> Subject: RE: [Emu] draft-cakulev-emu-eap-ibake >>=20 >> Hi Violeta, >>=20 >> What problem are you trying to solve with this EAP method? >>=20 >> Ciao >> Hannes >>=20 >>> -----Original Message----- >>> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf > Of >>> ext Cakulev, Violeta (Violeta) >>> Sent: Wednesday, January 11, 2012 10:16 PM >>> To: emu@ietf.org >>> Subject: [Emu] draft-cakulev-emu-eap-ibake >>>=20 >>> All, >>> Back in IETF 80 we presented EAP-IBAKE. The link to the I-D is >> provided >>> below: >>> http://tools.ietf.org/html/draft-cakulev-emu-eap-ibake-01 >>>=20 >>> This EAP method is based on the Identity-Based Authenticated Key >>> Exchange (IBAKE) protocol. IBAKE is a protocol for mutual >>> authentication and key agreement between two or more endpoints. It > is >>> based on a public-key based authentication mechanism, where each >>> message is encrypted with the public key of the corresponding >> endpoint, >>> as per the Identity Based Encryption (IBE) principles. As a result >> of >>> the IBAKE protocol, a shared symmetric key is generated by each >>> endpoint. >>>=20 >>> EAP-IBAKE is specified in ETSI TS 102 690 (stage 2) and ETSI TS 102 >> 921 >>> (stage 3) as a method for access network independent device and >> gateway >>> bootstrapping. >>> Both specifications are approved and are awaiting publication of > EAP- >>> IBAKE (among other things). >>>=20 >>> While this document could be of interest to emu WG, it would > probably >>> require changes to the WG charter. >>>=20 >>> Group's opinion about specifying EAP-IBAKE in emu WG as well as >>> possible changes to the WG charter is highly appreciated. >>>=20 >>> Thanks, >>> -Violeta >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Thu Jan 12 10:02:30 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B2221F8664 for ; Thu, 12 Jan 2012 10:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.008 X-Spam-Level: X-Spam-Status: No, score=-103.008 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0If-lREFR6bb for ; Thu, 12 Jan 2012 10:02:30 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6365D21F865C for ; Thu, 12 Jan 2012 10:02:30 -0800 (PST) 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 AA2AC203BA; Thu, 12 Jan 2012 13:01:55 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A65BF4974; Thu, 12 Jan 2012 13:02:28 -0500 (EST) From: Sam Hartman To: Hannes Tschofenig References: Date: Thu, 12 Jan 2012 13:02:28 -0500 In-Reply-To: (Hannes Tschofenig's message of "Thu, 12 Jan 2012 19:29:42 +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: draft-ietf-emu-chbind@tools.ietf.org, mrw@painless-security.com, Sam Hartman , emu@ietf.org Subject: Re: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 18:02:30 -0000 >>>>> "Hannes" == Hannes Tschofenig writes: Hannes> Hi Sam, let us start with the problem description: You claim Hannes> that EAP peer implementations use PK-based authentication Hannes> but do not do certificate validation. This obviously Hannes> introduces attacks (regardless of channel bindings, or Hannes> crypto bindings). Hannes> Any evidence that this is really a problem? And if it is a Hannes> problem why that cannot be fixed with a software update. If Hannes> you chose a specific EAP method then you obviously have to Hannes> deploy the necessary credentials and parameters at both end Hannes> points in order for it to work. As I went on to say, with the case of the eap tunnel method we're specifying here, usecase 3.9 of the requirements document requires that the method be secure if the inner method is sufficiently secure even if certificates are not checked. From jsalowey@cisco.com Thu Jan 12 10:16:07 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431A121F85CE for ; Thu, 12 Jan 2012 10:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egp2vA3pgV0S for ; Thu, 12 Jan 2012 10:16:06 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id EE47F21F8484 for ; Thu, 12 Jan 2012 10:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=15489; q=dns/txt; s=iport; t=1326392166; x=1327601766; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6oLHYWO+fPheJgMlOxwhRK0d1Q+RiVmOvok2rbn/yP4=; b=g9gP/R7C2d+VzMchg7k5UJdSMT9y1hsJyL5335QwRF3ZiM/pycyS69Kj J/42FbfqRCaAaWuH+po4GMxEBHxqKYfBjQJbWlfek1+9cZAwEVFmq2eXH H0atam3LxLwyVVvD4NDUCys4b3GlVrLO7C8S/WwqV75je5TQ28Yn7lgFx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABYiD0+rRDoG/2dsb2JhbAAtDQkOrHyBBYFyAQEBAwEBAQEPASc0CxALKwUWJzAGExQHB4dYCJk5AZ4QBIhXCiKCN2MEiDuMU4VRjDRY X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; d="scan'208";a="25107815" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 12 Jan 2012 18:16:05 +0000 Received: from [10.33.251.93] ([10.33.251.93]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0CIG4Z1007203; Thu, 12 Jan 2012 18:16:04 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Thu, 12 Jan 2012 10:16:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5916DC43-096B-4F88-9ACD-4675C2396316@cisco.com> References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: mrw@painless-security.com, draft-ietf-emu-chbind@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 18:16:07 -0000 Back when we were looking at the crypto binding problem, a MITM in the = infrastructure was not part of the threat model. We had some discussion = of this, but we decided were able to get away with just using the MSK = and that this would be easier for deployment since the EMSK wasn't = really available at the time.=20 With the Channel Bindings work the considerations in the threat model = have changed somewhat. It seems that taking this into consideration = now may be appropriate. Before deciding whether mutual cryptographic = binding is important I think we need to make sure we understand the = threat model that we are assuming since we currently have a gap. We may = find that just modifying the crypto-binding to use a key derived from = the EMSK to provide mutual crypto binding may not solve the general = problem of a MITM in the middle of the infrastructure. =20 Is the characterization of the attacker someone that is part of the = infrastructure and can impersonate a valid NAS/Proxy to the the AAA = server? =20 It seems that we are trying to minimize the threat that the attacker is = able to impersonate the AAA server. Are there other attacks? Since = part of the infrastructure is already compromised there are some threats = we can not affect. =20 I do think this needs to be discussed in the security considerations in = the tunnel method even if we decide it is not important to fix. It = probably should also be discussed in the channel bindings document as = well. =20 Joe =20 On Jan 11, 2012, at 12:33 PM, Sam Hartman wrote: >=20 > I'd like to thank Margaret Wasserman for coming up with a series of > proposed attacks that lead to the following comments. >=20 >=20 > In the context of implementing channel binding and a system that takes > advantage of it, I've been focusing on MITM attacks. I'd like to give = a > example of the sorts of attacks that are worrying me. I thought these > were supposed to be solved by crypto binding, but I no longer think = that > existing implementation of crypto binding are strong enough. >=20 > First, in a channel binding world, some NASes are significantly more > trusted than others. In my ABFAB world that's especially true. >=20 > We have clients using EAP-TTLS as a tunnel method with some inner > password method (MSCHAPv2, some PAKE method, whatever. We'll assume = that > it generates a key.) We're adding support the EAP-TTLS for channel > binding. That's realistic and is consistent with the approach we've = been > trying to standardize. We want the tunnel methods to support channel > binding and perform the channel binding exchange there so we don't = have > to modify all EAP methods. NEA needs something similar for data they > plan to transport over EAP. >=20 > Consider a compromised print server. It would like to impersonate > someone's bank. (In an ABFAb world, EAP is used for things other than > network access. I can construct a network access version of this = attack > if you'd like too.) >=20 > The print server impersonates the bank enough to get the client to > connect to it. It then starts authentication. We're using ABFAB to > authenticate the client to the server and the server to the client. = The > user indicates their home realm in an identity response.=20 > The print server, like the bank is a valid participant in the AAA > fabric. So it sends an access-request to the home EAP server and gets = a > method request. >=20 > In this attack the home EAP server uses TTLS. However the print server > wants to MITM the TTLS tunnel. So, while the print server sends the > first TTLS packet towards the client, it sends a EAP NACK towards the > home EAP server requesting the appropriate inner password method. >=20 > So, we start to establish a EAP tunnel between the client and the = print > server and an inner method between the client and the home EAP server. > Things will fail if the client validates the tunnel certificate. >=20 > However if the client goes forward, then the authentication will > succeed at the inner method level. >=20 > Then, assuming we're using TTLSv1, the client will do crypto > binding. Intuitively you'd kind of think that crypto binding would = help > here; I'll discuss in a bit whether it's supposed to. It's quite clear > it doesn't though. Crypto binding uses the MSK of the inner method for > the binding. However, as part of the access-accept, the home EAP = server > discloses the MSK to the print server. So, the print server has the > material it needs to perform crypto binding and the generate the final > MSK. >=20 > Then the client performs channel binding to confirm that it's talking = to > the bank. The print server is happy to tell the client that the print > server is in fact a bank, so the attack succeeds. >=20 > For the most part, this is a classic compound authentication attack. = If > the inner method had not been offered outside the tunnel, the attack > generally would not be possible. If different credentials are used, = when > the method is used inside a tunnel vs outside the attack is not > possible. As stated earlier, this particular instance of the attack = is > not possible if the client verifies the TTLS certificate. There are = also > ABFAB-specific mitigations that do not generally apply to network > access. >=20 > However, the client does have a secure connection to the home EAP > server. Intuitively, we do not actually need to require checking the > certificate to provide security against this. If the credential is = weak > and can be attacked with a passive dictionary attack, then other = attacks > may be possible if the client does not check the certificate. However = if > we're using a good PAKE method as an inner method and only using the > tunnel for carrying tunneled attributes such as channel binding, = there's > absolutely no reason the security of the system needs to depend on = that > certificate check. Whether we like it or not, there are a lot of = clients > out there that have weak validation of certificates for EAP tunnel > methods. >=20 > Intuitively, crypto binding is supposed to solve MITM attacks with > compound authentication. Certainly as I've discussed this issue with > some folks in the EAP community they've started out thinking that = crypto > binding was supposed to solve this sort of thing. > Let's go back to RFC 3748 and see what we actually specified for = crypto > binding though: >=20 > Cryptographic binding > The demonstration of the EAP peer to the EAP server that a = single > entity has acted as the EAP peer for all methods executed = within a > tunnel method. Binding MAY also imply that the EAP = server > demonstrates to the peer that a single entity = has acted as the EAP > server for all methods executed within = a tunnel method. If > executed correctly, binding = serves to mitigate man-in-the-middle > vulnerabilities. > =20 >=20 > So, from that definition it's clear that cryptographic binding doesn't > always provide a solution. In particular, this attack is concerned = with > situations where multiple servers are involved (and should not be) > rather than situations where multiple clients are involved.=20 > Proving to the client only one server is involved is an optional > facility in cryptographic binding. > Still, it looks that even in the time of RFC 3748 like people thought > that there are cases where we'd want to prove to a client that there = was > no MITM server. > It seems like if that optional facility is provided then we ought to > avoid this attack. >=20 > It's unfortunate that RFC 3748 doesn't name the optional facility = where > cryptographic binding provides defense against MITM servers. I'll call > that mutual cryptographic binding. >=20 > I'd like to step away from EAP-TTLS and focus on > draft-ietf-emu-eap-tunnel-method. If we're going to fix something or > document security considerations, let's do it for things we're > standardizing first. >=20 > I'm left with a number of questions: >=20 > 1) Is mutual cryptographic binding important? >=20 > 2) What do the tunnel method requirements say about this? >=20 > 3) Does the tunnel method document intend to provide mutual > cryptographic binding? Does it succeed? Should it? >=20 > 4) What protocol changes should we make? >=20 > 5) What security considerations should we document? >=20 >=20 > Sot >=20 >=20 > Discussion: 1) Is mutual cryptographic binding important? >=20 > So, we're starting to do a lot of new things with tunnels and EAP. = We're > exchanging channel bindings. We're exchanging NEA information. And = we're > defining extensible tunnel methods where it seems likely that people > will propose adding new facilities. > In today's EAP for network access situations, the client doesn't > actually get much out of the authentication. A lot of the value of EAP > is proving the identity of the peer to the EAP server and indirectly = the > NAS. > However, channel bindings, some NEA deployments and other potential = uses > of EAP increase the importance of the exchange to clients. > That is, there's a lot more value in a NAS attacking a client in the > future than there is today. >=20 > Channel bindings are of particular note in this regard because they > allow clients to distinguish NASes. >=20 > At the same time we're talking about standardizing anonymous > provisioning (Dan's comments) and otherwise doing things that create > cases where we don't expect clients to validate tunnel > certificates. We're also doing things that makes certificate = validation > easier in some cases. But even if we want to ignore deployments where > people simply don't validate certificates today, that doesn't = completely > make this issue go away. This is consistent with use case 3.9 in the > tunnel method requirements draft. >=20 > Let's also think for a moment about peer-side certificate > validation. It's not actually enough to simply validate that a > certificate is is traced back to a trust anchor. It's actually = critical > to validate the name of the certificate (or validate a fingerprint). I > think it's quite common for peers to be deployed in a configuration = that > does not check that the presented certificate is linked to a single > known and trusted EAP server. So, I think clients that do not validate > certificates are quite real. >=20 > For these reasons, I think this issue will be of increasing importance > in the future. >=20 > Discussion: 2) What do the tunnel method requirements say about this? >=20 > If you take a look at the bottom of page 6 in tunnel method > requirements, there is a discussion of MITM attacks. =46rom that > discussion, it sounds like cryptographic binding is believed to be an > adequate defense against tunnel MITM attacks for sufficiently strong > inner methods. The actual requirement for cryptographic binding is > defined in section 4.6.3. That section goes into a lot of detail about > how to implement cryptographic binding, but doesn't address the = question > of who is expected to be able to verify the cryptographic binding or > what keys are involved. However reading that section again it sounds > like the EAP tunnel method is intended to support cryptographic = binding > adequate to provide defense against tunnel MITM attacks. >=20 > It's still kind of ambiguous what was intended. Certainly, section = 3.9 > implies that the tunnel method needs to be secure when for example the > tunnel method is used to add channel binding to an otherwise secure > inner EAP method even when server certificates are not validated. >=20 >=20 >=20 > Discussion: 3) Does the tunnel method document intend to provide = mutual > cryptographic binding? Does it succeed? Should it? >=20 > Take a look at section 4.9.2 and 5.3 in = draft-ietf-emu-eap-tunnel-method > for the cryptographic binding in the current draft. > That section seems to be trying to authenticate the server to the > client. There is a copy of the server's compound MAC that is sent to = the > client. > Unfortunately, though, the MAC is protected by a combination of MSKs = and > the phase 1 keying information according to section 5.3. > So, the tunnel method is vulnerable to this class of attack. >=20 > do we want to fix it? I think so. There's one catch. It gets in the > way of terminating the tunnel at a different endpoint than the inner = EAP > method. Supporting that does not seem to be a requirement. I cannot > find any use cases in section 3 of the tunnel method requirements > document that requires support for termination. Section 6.4 of the > tunnel method requirements discusses the security problems that can > result with such termination and hints but does not require that = clients > be able to determine whether termination at different endpoints has > happened. >=20 > So, I think tunnel termination at different endpoints than the inner > method is at best second-class. I'd prefer to start from the = assumption > that it is not requirement. If the WG gets a consensus that it is a > requirement, then I'd prefer to adopt a solution to these MITM issues > that prohibits termination at different endpoints by default (in favor > of stronger security) but that allows a permissive client to accept no > cryptographic binding of servers in appropriately limited = circumstances. > I'll note that a lot of use cases such as channel binding where the > tunnel method is considered without certificate verification are > entirely inappropriate if the inner method is terminated at a = different > place than the tunnel method. >=20 >=20 > Discussion: 4) technical changes >=20 > The easiest fix seems to be to use the EMSK rather than the MSK to > produce the key for the compound MAC. We may want to consider using = the > EMSK to enfluence both the MSK and EMSK for the overall EAP tunnel > method. I believe that if the key is not known to the attacker the > construction in section 4.9.2 and 5.3 provides mutual cryptographic > binding. I believe that the EMSK of the inner method should not be = known > to the attacker because the EMSK is not disclosed beyond the EAP = server. >=20 > Discussion: 5) Security Considerations >=20 > I think we should actually clearly document the difference between > mutual cryptographic binding and cryptographic binding. > I think we should discuss cases where the mutual cryptographic binding > is important--namely cases where the client trusts the tunnel = especially > when it does not otherwise validate the tunnel. >=20 > If there are cases where we provide cryptographic binding but not = mutual > cryptographic binding, we should carefully discuss the risks. >=20 > Acknowledgements >=20 > I'd like to thank Margaret Wasserman and Jari Arkko for help in > reviewing my analysis. I'd especially like to thank Margaret for = finding > several attack situations in this space. >=20 > --Sam > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From violeta.cakulev@alcatel-lucent.com Thu Jan 12 10:41:30 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA83021F8690 for ; Thu, 12 Jan 2012 10:41:30 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rt-yPruyjCrG for ; Thu, 12 Jan 2012 10:41:29 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id ADEED21F8679 for ; Thu, 12 Jan 2012 10:41:29 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q0CIfNiI018406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2012 12:41:23 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0CIfNmu027944 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Jan 2012 12:41:23 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 12 Jan 2012 12:41:23 -0600 From: "Cakulev, Violeta (Violeta)" To: Hannes Tschofenig Date: Thu, 12 Jan 2012 12:41:20 -0600 Thread-Topic: [Emu] draft-cakulev-emu-eap-ibake Thread-Index: AczRUbO7qVBzyrpZSI+mC7sjNjjb3QABq8Uw Message-ID: References: <999913AB42CC9341B05A99BBF358718DFB4C4E@FIESEXC035.nsn-intra.net> <999913AB42CC9341B05A99BBF358718DFB50E5@FIESEXC035.nsn-intra.net> <54D56B18-BB76-44BC-B48B-3ED5E7DAE045@gmx.net> In-Reply-To: <54D56B18-BB76-44BC-B48B-3ED5E7DAE045@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "emu@ietf.org" Subject: Re: [Emu] draft-cakulev-emu-eap-ibake X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 18:41:30 -0000 Hannes, Indeed the I-D currently states Standards Track RFC, but as my original ema= il stated, we are trying to get WG's comments and opinion on the direction = we should take. Certainly, if emu WG is not interested we will change the i= ntended status. As for 'where to specify it', other standard bodies are still looking to IE= TF to publish IP-based protocols/methods instead of specifying it in the ap= pendix, which is the reason you've observed it many times in IETF. -Violeta -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] Sent: Thursday, January 12, 2012 12:43 PM To: Cakulev, Violeta (Violeta) Cc: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); emu@ietf.org Subject: Re: [Emu] draft-cakulev-emu-eap-ibake Hi Violeta, I am unfortunately familiar with the details of the ETSI Machine-to-Machine= specifications to judge whether your draft meets their design requirements= and fits into their architecture. I am sure lots of experts in ETSI have l= ooked at this problem and have made a thoughtful decision. I wish them good= luck deploying all their stuff. Having said that I feel that you are likely going into a problem that I hav= e observed many times in the IETF: folks typically want to understand the p= roblem they are trying to solve and they tend to be unsatisfied with the re= sponse "ETSI needs it.". Luckily things are looking good for you: If you do not seek publication of = this EAP method as a Standards Track RFC then the process is fairly simple.= In fact, you do not even go through the IETF to get a method ID. You can j= ust dump the draft text into the appendix of the ETSI specification, drop I= ANA a mail, and you are done with it. The story is quite different if you want to get this standardized as a Stan= dards Track RFC (which is what your draft currently says). Ciao Hannes On Jan 12, 2012, at 5:57 PM, Cakulev, Violeta (Violeta) wrote: > Hannes, > Thanks for the comments/opinions. > > While soliciting comments from CORE on EAP-IBAKE and bootstrapping in gen= eral would be most certainly helpful, ETSI M2M already concluded discussion= s on the choice of bootstrapping methods. > Both stage 2 (ETSI 102 690) and stage 3 (ETSI 102 921) are frozen and new= methods will not be taken into consideration for rel. 1. > > Given that EAP-IBAKE is a bootstrapping method in these specifications, w= e are trying to ensure appropriate review and timely publication of EAP-IBA= KE I-D. > > Regards, > > -Violeta > > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.c= om] > Sent: Thursday, January 12, 2012 10:23 AM > To: Cakulev, Violeta (Violeta); emu@ietf.org > Subject: RE: [Emu] draft-cakulev-emu-eap-ibake > > Hi Violeta, > > I believe it would be useful to solicit comments from a working group > like CORE, who works on this smart object space. In that group folks had > come up with their ideas on how to bootstrap security for these types of > devices. Of course, it has nothing to-do with identity based > cryptography. > > If you want to hear my personal opinion: I don't think that identity > based cryptography solves any real problems. > > Ciao > Hannes > >> -----Original Message----- >> From: ext Cakulev, Violeta (Violeta) [mailto:violeta.cakulev@alcatel- >> lucent.com] >> Sent: Thursday, January 12, 2012 5:17 PM >> To: Tschofenig, Hannes (NSN - FI/Espoo); emu@ietf.org >> Subject: RE: [Emu] draft-cakulev-emu-eap-ibake >> >> Hannes, >> Thanks for the interest. >> >> IBAKE was proposed and adopted as a method for device bootstrapping in >> ETSI M2M. >> IBAKE is especially suitable in this setting as it is a method that >> provides mutual authentication and key agreement without the need to >> rely on third parties such as certificate authorities. >> So the specific problem that is being solved in ETSI M2M with > EAP-IBAKE >> is device bootstrapping that is access network independent. >> >> Obviously, as an EAP method EAP-IBAKE can address many other problems >> (as numerous other EAP methods can). >> >> Regards, >> -Violeta >> >> -----Original Message----- >> From: Tschofenig, Hannes (NSN - FI/Espoo) >> [mailto:hannes.tschofenig@nsn.com] >> Sent: Thursday, January 12, 2012 2:08 AM >> To: Cakulev, Violeta (Violeta); emu@ietf.org >> Subject: RE: [Emu] draft-cakulev-emu-eap-ibake >> >> Hi Violeta, >> >> What problem are you trying to solve with this EAP method? >> >> Ciao >> Hannes >> >>> -----Original Message----- >>> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf > Of >>> ext Cakulev, Violeta (Violeta) >>> Sent: Wednesday, January 11, 2012 10:16 PM >>> To: emu@ietf.org >>> Subject: [Emu] draft-cakulev-emu-eap-ibake >>> >>> All, >>> Back in IETF 80 we presented EAP-IBAKE. The link to the I-D is >> provided >>> below: >>> http://tools.ietf.org/html/draft-cakulev-emu-eap-ibake-01 >>> >>> This EAP method is based on the Identity-Based Authenticated Key >>> Exchange (IBAKE) protocol. IBAKE is a protocol for mutual >>> authentication and key agreement between two or more endpoints. It > is >>> based on a public-key based authentication mechanism, where each >>> message is encrypted with the public key of the corresponding >> endpoint, >>> as per the Identity Based Encryption (IBE) principles. As a result >> of >>> the IBAKE protocol, a shared symmetric key is generated by each >>> endpoint. >>> >>> EAP-IBAKE is specified in ETSI TS 102 690 (stage 2) and ETSI TS 102 >> 921 >>> (stage 3) as a method for access network independent device and >> gateway >>> bootstrapping. >>> Both specifications are approved and are awaiting publication of > EAP- >>> IBAKE (among other things). >>> >>> While this document could be of interest to emu WG, it would > probably >>> require changes to the WG charter. >>> >>> Group's opinion about specifying EAP-IBAKE in emu WG as well as >>> possible changes to the WG charter is highly appreciated. >>> >>> Thanks, >>> -Violeta >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hzhou@cisco.com Thu Jan 12 10:42:47 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176AE21F867B for ; Thu, 12 Jan 2012 10:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKj+3Mog6P8z for ; Thu, 12 Jan 2012 10:42:45 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 60F3021F8679 for ; Thu, 12 Jan 2012 10:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=16345; q=dns/txt; s=iport; t=1326393765; x=1327603365; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=kYpj0uj+qhroFYnRJX0uiIZPIil9IucQVRoC6LZo/AI=; b=J4e6eeKySZsOSLyrsQikJVdmmzHXiSmBjGKIXHhcqWeB5+R71ZrKCp36 q+NlKQyFd9ZS0y5Z9PtLXkxE5f38ALv9VBV5K5cJ06Z4MlqlFusz2HiBw S4K42yoT9zxzgi+u5uzq+h+Sm09CmsqPjKoa+Eos+OAngI9C0OOhTUs1A I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAGAMEoD0+tJXG//2dsb2JhbAAtDQkOrHwCgQWBcgEBAQMBAQEBDwEnAgExCwUNAQgOChMFPTABAQQBDQUUBweHWAiZMwGeDgSIVwoigxoEiDuMU5IFVQ X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; d="scan'208";a="50742430" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 12 Jan 2012 18:42:44 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0CIgi3I025792; Thu, 12 Jan 2012 18:42:44 GMT Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 12:42:44 -0600 Received: from 64.101.219.77 ([64.101.219.77]) by XMB-RCD-203.cisco.com ([72.163.62.210]) via Exchange Front-End Server email.cisco.com ([72.163.62.137]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Jan 2012 18:42:43 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 12 Jan 2012 13:42:37 -0500 From: Hao Zhou To: Joe Salowey , Sam Hartman Message-ID: Thread-Topic: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method Thread-Index: AczRWfRtfoleZViHyk+pSsz9LJ/0lQ== In-Reply-To: <5916DC43-096B-4F88-9ACD-4675C2396316@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Jan 2012 18:42:44.0299 (UTC) FILETIME=[F8C709B0:01CCD159] Cc: mrw@painless-security.com, draft-ietf-emu-chbind@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 18:42:47 -0000 Ditto. The attack crypto-binding was originally designed is to prevent MITM endpoint, not an MITM in the AAA infrastructure. The case described here is legit AAA client acting as the EAP server, in fact no different than a legit AAA server with an inner method server, other than the client is not verifying the EAP server cert. Once this basic trust is compromised, there might be other attacks. Using EMSK might not work, as many legacy methods doesn't even have EMSK, and it will also prevent existing AAA server with inner method working. I do agree we need to document this in the security section, especially the limitation of current crypto-binding and this potential attack. On 1/12/12 1:16 PM, "Joe Salowey" wrote: > Back when we were looking at the crypto binding problem, a MITM in the > infrastructure was not part of the threat model. We had some discussion of > this, but we decided were able to get away with just using the MSK and that > this would be easier for deployment since the EMSK wasn't really available at > the time. > > With the Channel Bindings work the considerations in the threat model have > changed somewhat. It seems that taking this into consideration now may be > appropriate. Before deciding whether mutual cryptographic binding is > important I think we need to make sure we understand the threat model that we > are assuming since we currently have a gap. We may find that just modifying > the crypto-binding to use a key derived from the EMSK to provide mutual crypto > binding may not solve the general problem of a MITM in the middle of the > infrastructure. > > Is the characterization of the attacker someone that is part of the > infrastructure and can impersonate a valid NAS/Proxy to the the AAA server? > > It seems that we are trying to minimize the threat that the attacker is able > to impersonate the AAA server. Are there other attacks? Since part of the > infrastructure is already compromised there are some threats we can not > affect. > > I do think this needs to be discussed in the security considerations in the > tunnel method even if we decide it is not important to fix. It probably > should also be discussed in the channel bindings document as well. > > Joe > > On Jan 11, 2012, at 12:33 PM, Sam Hartman wrote: > >> >> I'd like to thank Margaret Wasserman for coming up with a series of >> proposed attacks that lead to the following comments. >> >> >> In the context of implementing channel binding and a system that takes >> advantage of it, I've been focusing on MITM attacks. I'd like to give a >> example of the sorts of attacks that are worrying me. I thought these >> were supposed to be solved by crypto binding, but I no longer think that >> existing implementation of crypto binding are strong enough. >> >> First, in a channel binding world, some NASes are significantly more >> trusted than others. In my ABFAB world that's especially true. >> >> We have clients using EAP-TTLS as a tunnel method with some inner >> password method (MSCHAPv2, some PAKE method, whatever. We'll assume that >> it generates a key.) We're adding support the EAP-TTLS for channel >> binding. That's realistic and is consistent with the approach we've been >> trying to standardize. We want the tunnel methods to support channel >> binding and perform the channel binding exchange there so we don't have >> to modify all EAP methods. NEA needs something similar for data they >> plan to transport over EAP. >> >> Consider a compromised print server. It would like to impersonate >> someone's bank. (In an ABFAb world, EAP is used for things other than >> network access. I can construct a network access version of this attack >> if you'd like too.) >> >> The print server impersonates the bank enough to get the client to >> connect to it. It then starts authentication. We're using ABFAB to >> authenticate the client to the server and the server to the client. The >> user indicates their home realm in an identity response. >> The print server, like the bank is a valid participant in the AAA >> fabric. So it sends an access-request to the home EAP server and gets a >> method request. >> >> In this attack the home EAP server uses TTLS. However the print server >> wants to MITM the TTLS tunnel. So, while the print server sends the >> first TTLS packet towards the client, it sends a EAP NACK towards the >> home EAP server requesting the appropriate inner password method. >> >> So, we start to establish a EAP tunnel between the client and the print >> server and an inner method between the client and the home EAP server. >> Things will fail if the client validates the tunnel certificate. >> >> However if the client goes forward, then the authentication will >> succeed at the inner method level. >> >> Then, assuming we're using TTLSv1, the client will do crypto >> binding. Intuitively you'd kind of think that crypto binding would help >> here; I'll discuss in a bit whether it's supposed to. It's quite clear >> it doesn't though. Crypto binding uses the MSK of the inner method for >> the binding. However, as part of the access-accept, the home EAP server >> discloses the MSK to the print server. So, the print server has the >> material it needs to perform crypto binding and the generate the final >> MSK. >> >> Then the client performs channel binding to confirm that it's talking to >> the bank. The print server is happy to tell the client that the print >> server is in fact a bank, so the attack succeeds. >> >> For the most part, this is a classic compound authentication attack. If >> the inner method had not been offered outside the tunnel, the attack >> generally would not be possible. If different credentials are used, when >> the method is used inside a tunnel vs outside the attack is not >> possible. As stated earlier, this particular instance of the attack is >> not possible if the client verifies the TTLS certificate. There are also >> ABFAB-specific mitigations that do not generally apply to network >> access. >> >> However, the client does have a secure connection to the home EAP >> server. Intuitively, we do not actually need to require checking the >> certificate to provide security against this. If the credential is weak >> and can be attacked with a passive dictionary attack, then other attacks >> may be possible if the client does not check the certificate. However if >> we're using a good PAKE method as an inner method and only using the >> tunnel for carrying tunneled attributes such as channel binding, there's >> absolutely no reason the security of the system needs to depend on that >> certificate check. Whether we like it or not, there are a lot of clients >> out there that have weak validation of certificates for EAP tunnel >> methods. >> >> Intuitively, crypto binding is supposed to solve MITM attacks with >> compound authentication. Certainly as I've discussed this issue with >> some folks in the EAP community they've started out thinking that crypto >> binding was supposed to solve this sort of thing. >> Let's go back to RFC 3748 and see what we actually specified for crypto >> binding though: >> >> Cryptographic binding >> The demonstration of the EAP peer to the EAP server that a single >> entity has acted as the EAP peer for all methods executed within a >> tunnel method. Binding MAY also imply that the EAP server >> demonstrates to the peer that a single entity has acted as the EAP >> server for all methods executed within a tunnel method. If >> executed correctly, binding serves to mitigate man-in-the-middle >> vulnerabilities. >> >> >> So, from that definition it's clear that cryptographic binding doesn't >> always provide a solution. In particular, this attack is concerned with >> situations where multiple servers are involved (and should not be) >> rather than situations where multiple clients are involved. >> Proving to the client only one server is involved is an optional >> facility in cryptographic binding. >> Still, it looks that even in the time of RFC 3748 like people thought >> that there are cases where we'd want to prove to a client that there was >> no MITM server. >> It seems like if that optional facility is provided then we ought to >> avoid this attack. >> >> It's unfortunate that RFC 3748 doesn't name the optional facility where >> cryptographic binding provides defense against MITM servers. I'll call >> that mutual cryptographic binding. >> >> I'd like to step away from EAP-TTLS and focus on >> draft-ietf-emu-eap-tunnel-method. If we're going to fix something or >> document security considerations, let's do it for things we're >> standardizing first. >> >> I'm left with a number of questions: >> >> 1) Is mutual cryptographic binding important? >> >> 2) What do the tunnel method requirements say about this? >> >> 3) Does the tunnel method document intend to provide mutual >> cryptographic binding? Does it succeed? Should it? >> >> 4) What protocol changes should we make? >> >> 5) What security considerations should we document? >> >> >> Sot >> >> >> Discussion: 1) Is mutual cryptographic binding important? >> >> So, we're starting to do a lot of new things with tunnels and EAP. We're >> exchanging channel bindings. We're exchanging NEA information. And we're >> defining extensible tunnel methods where it seems likely that people >> will propose adding new facilities. >> In today's EAP for network access situations, the client doesn't >> actually get much out of the authentication. A lot of the value of EAP >> is proving the identity of the peer to the EAP server and indirectly the >> NAS. >> However, channel bindings, some NEA deployments and other potential uses >> of EAP increase the importance of the exchange to clients. >> That is, there's a lot more value in a NAS attacking a client in the >> future than there is today. >> >> Channel bindings are of particular note in this regard because they >> allow clients to distinguish NASes. >> >> At the same time we're talking about standardizing anonymous >> provisioning (Dan's comments) and otherwise doing things that create >> cases where we don't expect clients to validate tunnel >> certificates. We're also doing things that makes certificate validation >> easier in some cases. But even if we want to ignore deployments where >> people simply don't validate certificates today, that doesn't completely >> make this issue go away. This is consistent with use case 3.9 in the >> tunnel method requirements draft. >> >> Let's also think for a moment about peer-side certificate >> validation. It's not actually enough to simply validate that a >> certificate is is traced back to a trust anchor. It's actually critical >> to validate the name of the certificate (or validate a fingerprint). I >> think it's quite common for peers to be deployed in a configuration that >> does not check that the presented certificate is linked to a single >> known and trusted EAP server. So, I think clients that do not validate >> certificates are quite real. >> >> For these reasons, I think this issue will be of increasing importance >> in the future. >> >> Discussion: 2) What do the tunnel method requirements say about this? >> >> If you take a look at the bottom of page 6 in tunnel method >> requirements, there is a discussion of MITM attacks. From that >> discussion, it sounds like cryptographic binding is believed to be an >> adequate defense against tunnel MITM attacks for sufficiently strong >> inner methods. The actual requirement for cryptographic binding is >> defined in section 4.6.3. That section goes into a lot of detail about >> how to implement cryptographic binding, but doesn't address the question >> of who is expected to be able to verify the cryptographic binding or >> what keys are involved. However reading that section again it sounds >> like the EAP tunnel method is intended to support cryptographic binding >> adequate to provide defense against tunnel MITM attacks. >> >> It's still kind of ambiguous what was intended. Certainly, section 3.9 >> implies that the tunnel method needs to be secure when for example the >> tunnel method is used to add channel binding to an otherwise secure >> inner EAP method even when server certificates are not validated. >> >> >> >> Discussion: 3) Does the tunnel method document intend to provide mutual >> cryptographic binding? Does it succeed? Should it? >> >> Take a look at section 4.9.2 and 5.3 in draft-ietf-emu-eap-tunnel-method >> for the cryptographic binding in the current draft. >> That section seems to be trying to authenticate the server to the >> client. There is a copy of the server's compound MAC that is sent to the >> client. >> Unfortunately, though, the MAC is protected by a combination of MSKs and >> the phase 1 keying information according to section 5.3. >> So, the tunnel method is vulnerable to this class of attack. >> >> do we want to fix it? I think so. There's one catch. It gets in the >> way of terminating the tunnel at a different endpoint than the inner EAP >> method. Supporting that does not seem to be a requirement. I cannot >> find any use cases in section 3 of the tunnel method requirements >> document that requires support for termination. Section 6.4 of the >> tunnel method requirements discusses the security problems that can >> result with such termination and hints but does not require that clients >> be able to determine whether termination at different endpoints has >> happened. >> >> So, I think tunnel termination at different endpoints than the inner >> method is at best second-class. I'd prefer to start from the assumption >> that it is not requirement. If the WG gets a consensus that it is a >> requirement, then I'd prefer to adopt a solution to these MITM issues >> that prohibits termination at different endpoints by default (in favor >> of stronger security) but that allows a permissive client to accept no >> cryptographic binding of servers in appropriately limited circumstances. >> I'll note that a lot of use cases such as channel binding where the >> tunnel method is considered without certificate verification are >> entirely inappropriate if the inner method is terminated at a different >> place than the tunnel method. >> >> >> Discussion: 4) technical changes >> >> The easiest fix seems to be to use the EMSK rather than the MSK to >> produce the key for the compound MAC. We may want to consider using the >> EMSK to enfluence both the MSK and EMSK for the overall EAP tunnel >> method. I believe that if the key is not known to the attacker the >> construction in section 4.9.2 and 5.3 provides mutual cryptographic >> binding. I believe that the EMSK of the inner method should not be known >> to the attacker because the EMSK is not disclosed beyond the EAP server. >> >> Discussion: 5) Security Considerations >> >> I think we should actually clearly document the difference between >> mutual cryptographic binding and cryptographic binding. >> I think we should discuss cases where the mutual cryptographic binding >> is important--namely cases where the client trusts the tunnel especially >> when it does not otherwise validate the tunnel. >> >> If there are cases where we provide cryptographic binding but not mutual >> cryptographic binding, we should carefully discuss the risks. >> >> Acknowledgements >> >> I'd like to thank Margaret Wasserman and Jari Arkko for help in >> reviewing my analysis. I'd especially like to thank Margaret for finding >> several attack situations in this space. >> >> --Sam >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Thu Jan 12 11:11:55 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3CE21F85E6 for ; Thu, 12 Jan 2012 11:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.915 X-Spam-Level: X-Spam-Status: No, score=-102.915 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+bGAexArQjW for ; Thu, 12 Jan 2012 11:11:55 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 40C3621F8574 for ; Thu, 12 Jan 2012 11:11:55 -0800 (PST) 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 BE4DA203BA; Thu, 12 Jan 2012 14:11:18 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1E99F4974; Thu, 12 Jan 2012 14:11:51 -0500 (EST) From: Sam Hartman To: Joe Salowey References: <5916DC43-096B-4F88-9ACD-4675C2396316@cisco.com> Date: Thu, 12 Jan 2012 14:11:51 -0500 In-Reply-To: <5916DC43-096B-4F88-9ACD-4675C2396316@cisco.com> (Joe Salowey's message of "Thu, 12 Jan 2012 10:16:38 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-emu-chbind@tools.ietf.org, mrw@painless-security.com, Sam Hartman , emu@ietf.org Subject: Re: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 19:11:55 -0000 >>>>> "Joe" == Joe Salowey writes: Joe> Back when we were looking at the crypto binding problem, a MITM Joe> in the infrastructure was not part of the threat model. We had Joe> some discussion of this, but we decided were able to get away Joe> with just using the MSK and that this would be easier for Joe> deployment since the EMSK wasn't really available at the time. Joe> With the Channel Bindings work the considerations in the threat Joe> model have changed somewhat. It seems that taking this into Joe> consideration now may be appropriate. Before deciding whether Joe> mutual cryptographic binding is important I think we need to Joe> make sure we understand the threat model that we are assuming Joe> since we currently have a gap. We may find that just modifying Joe> the crypto-binding to use a key derived from the EMSK to Joe> provide mutual crypto binding may not solve the general problem Joe> of a MITM in the middle of the infrastructure. Joe> Is the characterization of the attacker someone that is part of Joe> the infrastructure and can impersonate a valid NAS/Proxy to the Joe> the AAA server? That's a true characterization of the attacker, but I think it is very misleading. first, it's easy to dismiss: the infrastructure is secure, why are you worrying about this. Second, it tends to get wrapped around treating all infrastructure compromises the same, which I think will not be productive. Finally, it fails to account for the change in value of the system that is leading to the threat model change. I think the common elements in these attacks are: 1) The client trusts some parts of the infrastructure more than others. 2) The client uses information from the infrastructure to make decisions and cares about which infrastructure component it is from. Here are some examples of this: In NEA, there are components responsible for generating posture policy and giving clients posture assessment that are more trusted. A client might reasonably care about a compromise of these components more than a compromise of some access point. In channel bindings, the client explicitly wants to separate the infrastructure into trust classes. That's basically the primary thing channel bindings do. The client wants to make decisions about whether to use a service and on how to use a service based on what service it is. Explicit in the channel binding design is that some services might benefit from impersonating other services and channel bindings is part of a technical means to prevent that. I think that is inherently a threat model change requiring that one NAS not be able to impersonate another. --Sam From jsalowey@cisco.com Thu Jan 12 13:55:37 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407D221F8680 for ; Thu, 12 Jan 2012 13:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+osnE8kEkFM for ; Thu, 12 Jan 2012 13:55:36 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4A21B21F867E for ; Thu, 12 Jan 2012 13:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=3956; q=dns/txt; s=iport; t=1326405336; x=1327614936; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vfV+W9PBAS48FtByNvueuah5oXWsMms4gplsKfV6PZU=; b=Iq9IacKgSRGldTqID0RMfvCwi4msuz26Vy7yzTFCjtpJjazQcNSpQTaO fHNtrClW195HHFQnOcZv3FV+ZetOyDlY4dk4BQ0t2Pt2nZem6yOn5qyPG HVivQOl3FniavlWsHv6AXnryD7cwgaqJLpiAW+4y1nfn+j4b5qny/D241 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKFVD0+rRDoG/2dsb2JhbABDDqx/gQWBcgEBAQQSASc/EAstGVcGEyKgdQGeBoh1gkVjBIg7jFOFUYw0WA X-IronPort-AV: E=Sophos;i="4.71,500,1320624000"; d="scan'208";a="25150599" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 12 Jan 2012 21:55:36 +0000 Received: from [10.33.251.93] ([10.33.251.93]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0CLtZLb031642; Thu, 12 Jan 2012 21:55:35 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Thu, 12 Jan 2012 13:56:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <56B0390D-EA12-49BD-B148-6449A0AE755C@cisco.com> References: <5916DC43-096B-4F88-9ACD-4675C2396316@cisco.com> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: mrw@painless-security.com, draft-ietf-emu-chbind@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 21:55:37 -0000 I agree that not all infrastructure attacks are the same. I wasn't = trying to be misleading. What is important is that we are clear about = what we are attempting and claiming to solve and what the assumptions = are. =20 THere are somethings we may not be able to protect against. For example = we may not be able to protect against a rogue NAS that is part of the = infrastructure that is misbehaving but still operating within its = authorized parameters or under the authorized parameters of some = intermediate compromised proxy. I think this is the point that Glen = was bringing up in the meeting Taiwan. =20 FWIW, I think we should take this into consideration in the tunnel = method. The EMSK is defined for most methods now. One concern is that = some implementations may not export it yet. Another concern is that we = understand what we are really fixing and we don't over or under sell it. = =20 Cheers, Joe On Jan 12, 2012, at 11:11 AM, Sam Hartman wrote: >>>>>> "Joe" =3D=3D Joe Salowey writes: >=20 > Joe> Back when we were looking at the crypto binding problem, a = MITM > Joe> in the infrastructure was not part of the threat model. We = had > Joe> some discussion of this, but we decided were able to get away > Joe> with just using the MSK and that this would be easier for > Joe> deployment since the EMSK wasn't really available at the time. > Joe> With the Channel Bindings work the considerations in the = threat > Joe> model have changed somewhat. It seems that taking this into > Joe> consideration now may be appropriate. Before deciding whether > Joe> mutual cryptographic binding is important I think we need to > Joe> make sure we understand the threat model that we are assuming > Joe> since we currently have a gap. We may find that just = modifying > Joe> the crypto-binding to use a key derived from the EMSK to > Joe> provide mutual crypto binding may not solve the general = problem > Joe> of a MITM in the middle of the infrastructure. >=20 > Joe> Is the characterization of the attacker someone that is part = of > Joe> the infrastructure and can impersonate a valid NAS/Proxy to = the > Joe> the AAA server? >=20 > That's a true characterization of the attacker, but I think it is very > misleading. first, it's easy to dismiss: the infrastructure is = secure, > why are you worrying about this. Second, it tends to get wrapped = around > treating all infrastructure compromises the same, which I think will = not > be productive. Finally, it fails to account for the change in value = of > the system that is leading to the threat model change. >=20 > I think the common elements in these attacks are: >=20 > 1) The client trusts some parts of the infrastructure more than = others. >=20 > 2) The client uses information from the infrastructure to make = decisions > and cares about which infrastructure component it is from. >=20 > Here are some examples of this: >=20 > In NEA, there are components responsible for generating posture policy > and giving clients posture assessment that are more trusted. A client > might reasonably care about a compromise of these components more than = a > compromise of some access point. >=20 > In channel bindings, the client explicitly wants to separate the > infrastructure into trust classes. That's basically the primary thing > channel bindings do. The client wants to make decisions about whether = to > use a service and on how to use a service based on what service it > is. Explicit in the channel binding design is that some services might > benefit from impersonating other services and channel bindings is part > of a technical means to prevent that. I think that is inherently a > threat model change requiring that one NAS not be able to impersonate > another. >=20 > --Sam From aland@deployingradius.com Fri Jan 13 01:56:24 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95B921F8575 for ; Fri, 13 Jan 2012 01:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMcNrzI7ee9s for ; Fri, 13 Jan 2012 01:56:24 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 2B08821F8516 for ; Fri, 13 Jan 2012 01:56:24 -0800 (PST) Message-ID: <4F0FFFAA.5010308@deployingradius.com> Date: Fri, 13 Jan 2012 10:55:54 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <4F0EBA3A.4040300@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mrw@painless-security.com, draft-ietf-emu-chbind@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 09:56:24 -0000 Sam Hartman wrote: > RFc 5281 does not provide cryptographic binding. Well, then I either misunderstand 5281, or I misunderstand what crypto binding is. I thought that crypto binding was used to bind the results of chained key generating methods together or to an encompassing tunnel. Which is what is done in 5281. > In RFC 5281 there is no cryptographic binding, so the attack trivially > succeeds without using the inner MSK. There is no inner MSK with TTLS or PEAP. (PAP, CHAP, MS-CHAP, EAP-MD5, or EAP-MSCHAP in the inner tunnel) > As I read RFC 5281, the implicit challenge described in section 11.1 is > only used if one of the implicit (non-EAP) tunneled authentications is > used, as described say in section 11.2.2. > However if EAP is used as described in 11.2.1, then the implicit > challenge in 11.1 is not used. OK. I had misremembered that part. > No. > > The attacker controls the outer TLS session. The attacker knows the MSK. > The keys need to be derived from something the attacker does not know in > order to avoid an attack. OK. Alan DeKok. From hartmans@mit.edu Fri Jan 13 08:01:03 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A2021F85A5 for ; Fri, 13 Jan 2012 08:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.002 X-Spam-Level: X-Spam-Status: No, score=-103.002 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgObrTyBqPjH for ; Fri, 13 Jan 2012 08:01:02 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A0AC821F859E for ; Fri, 13 Jan 2012 08:01:02 -0800 (PST) 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 B164E201C9; Fri, 13 Jan 2012 11:00:24 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 05BE5434F; Fri, 13 Jan 2012 11:00:56 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <4F0EBA3A.4040300@deployingradius.com> <4F0FFFAA.5010308@deployingradius.com> Date: Fri, 13 Jan 2012 11:00:56 -0500 In-Reply-To: <4F0FFFAA.5010308@deployingradius.com> (Alan DeKok's message of "Fri, 13 Jan 2012 10:55:54 +0100") 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: draft-ietf-emu-chbind@tools.ietf.org, mrw@painless-security.com, Sam Hartman , emu@ietf.org Subject: Re: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 16:01:03 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Sam Hartman wrote: >> RFc 5281 does not provide cryptographic binding. Alan> Well, then I either misunderstand 5281, or I misunderstand Alan> what crypto binding is. I thought that crypto binding was Alan> used to bind the results of chained key generating methods Alan> together or to an encompassing tunnel. This is most of crypto binding. The additional thing crypto binding needs to do is to chain these keys together in a manner that detects man-in-the-middle attacks. I can't find anything in RFC 5281 that does that. In fact, RFc 5281 is explicitly designed to permit man-in-the-middle attacks, on the grounds that the TTLS server may be different from the AAA server/EAP server. There's a discussion of crypto binding in RFC 5281 that specifically says there is none but points to some proposals for the future. TTLSv1 does appear to have crypto binding based on code analysis when you're using an inner EAP method that generates an MSK. TTLSv1 neither tries to nor has mutual crypto binding. >> In RFC 5281 there is no cryptographic binding, so the attack >> trivially succeeds without using the inner MSK. Alan> There is no inner MSK with TTLS or PEAP. (PAP, CHAP, Alan> MS-CHAP, EAP-MD5, or EAP-MSCHAP in the inner tunnel) I think what you're saying here is there are a lot of non-keyed EAP methods and if you use them as an inner method then you don't get an inner MSK. Absolutely right; if we want to defend against the sort of attacks I was bringing up here for these methods your solution (something based on user credentials) is the only thing that would work. As you already said, nothing can save PAP:-) So, here's where I'm at in decreasing order of priority: 1) document security considerations; I think everyone can agree on this. 2) Provide mutual crypto binding for tunnels using an inner method with an EMSK 3) Figure out if we want to do something like what you propose using long-term credentials for inner methods that don't have an EMSK. From aland@deployingradius.com Fri Jan 13 08:15:03 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8CE21F85AE for ; Fri, 13 Jan 2012 08:15:03 -0800 (PST) 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.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abuOJJea9dPZ for ; Fri, 13 Jan 2012 08:15:03 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DD6BB21F85AD for ; Fri, 13 Jan 2012 08:15:02 -0800 (PST) Message-ID: <4F105868.8090107@deployingradius.com> Date: Fri, 13 Jan 2012 17:14:32 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <4F0EBA3A.4040300@deployingradius.com> <4F0FFFAA.5010308@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mrw@painless-security.com, draft-ietf-emu-chbind@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 16:15:04 -0000 Sam Hartman wrote: > The additional thing crypto binding needs to do is to chain these keys > together in a manner that detects man-in-the-middle attacks. > I can't find anything in RFC 5281 that does that. OK. I think we're converging. > So, here's where I'm at in decreasing order of priority: > > 1) document security considerations; I think everyone can agree on this. Yes. Details to come. At the minimum, a discussion of the certificate attacks and provisioning would be useful. i.e. doing provisioning when you don't trust *anyone* is a bad idea. Provisioning on a known / secure network is a much better idea. For certificates, when user@realm authenticates, the goal is to have an AAA server in that realm terminate the TLS tunnel. What implications does that have for the system? > 2) Provide mutual crypto binding for tunnels using an inner method with > an EMSK Yes. > 3) Figure out if we want to do something like what you propose using > long-term credentials for inner methods that don't have an EMSK. That's a wider discussion for the WG. I'd like to see more input. Alan DeKok. From hannes.tschofenig@gmx.net Sun Jan 15 08:17:08 2012 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D6B21F84BD for ; Sun, 15 Jan 2012 08:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCCwL-EZLDNv for ; Sun, 15 Jan 2012 08:17:07 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0B1BC21F8474 for ; Sun, 15 Jan 2012 08:17:06 -0800 (PST) Received: (qmail invoked by alias); 15 Jan 2012 16:17:05 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.216.191] by mail.gmx.net (mp023) with SMTP; 15 Jan 2012 17:17:05 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/+gDNalBD+DMIxTxZT0N7x14aaEgfRgz5dR5IDeT JGQH60IkXLTWhj Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sun, 15 Jan 2012 18:17:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1B7F8AAF-273D-4ADD-9777-9B413D915814@gmx.net> References: <999913AB42CC9341B05A99BBF358718DFB4C4E@FIESEXC035.nsn-intra.net> <999913AB42CC9341B05A99BBF358718DFB50E5@FIESEXC035.nsn-intra.net> <54D56B18-BB76-44BC-B48B-3ED5E7DAE045@gmx.net> To: "Cakulev, Violeta (Violeta)" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "emu@ietf.org" Subject: Re: [Emu] draft-cakulev-emu-eap-ibake X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 16:17:08 -0000 Hi Violeta,=20 On Jan 12, 2012, at 8:41 PM, Cakulev, Violeta (Violeta) wrote: > Hannes, > Indeed the I-D currently states Standards Track RFC, but as my = original email stated, we are trying to get WG's comments and opinion on = the direction we should take. Certainly, if emu WG is not interested we = will change the intended status. >=20 I personally believe that you will not get the necessary support from = the EMU working group to get the charter changed and the group = interested in IBE.=20 I can tell you that I will not spend my time on it.=20 My reasons are being less excited are:=20 * Identity based crypto as a technology does not really solve a problem. = (In case you are going to ask: "yes" I looked it some time ago when I = tried to figure out what value it provides for some IETF protocols. And = guess what - I couldn't find any benefits.) * "ETSI wants it" is not a good reason for me todo anything. * I have so many other great documents to review.=20 * The IPR situation with identity based crypto makes me feel uneasy.=20 > As for 'where to specify it', other standard bodies are still looking = to IETF to publish IP-based protocols/methods instead of specifying it = in the appendix, which is the reason you've observed it many times in = IETF. For specifications where the policies for extending protocol requires = you to come to the IETF then you should obviously do that. In case of = EAP methods that is not needed. That's great - you should be = celebrating. If you look around there are a couple of other technologies = ETSI has been working on where the IETF was not involved, such as = extensions to Diameter in form of new AVPs and new Diameter = applications. They had no problems with that either.=20 I would even say that specifications should only be published in the = IETF stream if there is interest by IETF participants. An example from a = different area: I have seen requests for MIKE key exchange protocols = coming to the IETF where there was absolutely not interest in the IETF = but the policy for new MIKEY extension required IETF Standards Track = specifications. This lead to the publication of specifications that = barely anyone reviewed and nobody wants (other than the authors). = Needless to say that I have my doubts about the bright deployment future = of these protocols.=20 Ciao Hannes PS: Consider my public feedback as a friendly advice that will help you = save a few years of work. >=20 > -Violeta >=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Thursday, January 12, 2012 12:43 PM > To: Cakulev, Violeta (Violeta) > Cc: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); = emu@ietf.org > Subject: Re: [Emu] draft-cakulev-emu-eap-ibake >=20 > Hi Violeta, >=20 > I am unfortunately familiar with the details of the ETSI = Machine-to-Machine specifications to judge whether your draft meets = their design requirements and fits into their architecture. I am sure = lots of experts in ETSI have looked at this problem and have made a = thoughtful decision. I wish them good luck deploying all their stuff. >=20 > Having said that I feel that you are likely going into a problem that = I have observed many times in the IETF: folks typically want to = understand the problem they are trying to solve and they tend to be = unsatisfied with the response "ETSI needs it.". >=20 > Luckily things are looking good for you: If you do not seek = publication of this EAP method as a Standards Track RFC then the process = is fairly simple. In fact, you do not even go through the IETF to get a = method ID. You can just dump the draft text into the appendix of the = ETSI specification, drop IANA a mail, and you are done with it. >=20 > The story is quite different if you want to get this standardized as a = Standards Track RFC (which is what your draft currently says). >=20 > Ciao > Hannes >=20 > On Jan 12, 2012, at 5:57 PM, Cakulev, Violeta (Violeta) wrote: >=20 >> Hannes, >> Thanks for the comments/opinions. >>=20 >> While soliciting comments from CORE on EAP-IBAKE and bootstrapping in = general would be most certainly helpful, ETSI M2M already concluded = discussions on the choice of bootstrapping methods. >> Both stage 2 (ETSI 102 690) and stage 3 (ETSI 102 921) are frozen and = new methods will not be taken into consideration for rel. 1. >>=20 >> Given that EAP-IBAKE is a bootstrapping method in these = specifications, we are trying to ensure appropriate review and timely = publication of EAP-IBAKE I-D. >>=20 >> Regards, >>=20 >> -Violeta >>=20 >> -----Original Message----- >> From: Tschofenig, Hannes (NSN - FI/Espoo) = [mailto:hannes.tschofenig@nsn.com] >> Sent: Thursday, January 12, 2012 10:23 AM >> To: Cakulev, Violeta (Violeta); emu@ietf.org >> Subject: RE: [Emu] draft-cakulev-emu-eap-ibake >>=20 >> Hi Violeta, >>=20 >> I believe it would be useful to solicit comments from a working group >> like CORE, who works on this smart object space. In that group folks = had >> come up with their ideas on how to bootstrap security for these types = of >> devices. Of course, it has nothing to-do with identity based >> cryptography. >>=20 >> If you want to hear my personal opinion: I don't think that identity >> based cryptography solves any real problems. >>=20 >> Ciao >> Hannes >>=20 >>> -----Original Message----- >>> From: ext Cakulev, Violeta (Violeta) = [mailto:violeta.cakulev@alcatel- >>> lucent.com] >>> Sent: Thursday, January 12, 2012 5:17 PM >>> To: Tschofenig, Hannes (NSN - FI/Espoo); emu@ietf.org >>> Subject: RE: [Emu] draft-cakulev-emu-eap-ibake >>>=20 >>> Hannes, >>> Thanks for the interest. >>>=20 >>> IBAKE was proposed and adopted as a method for device bootstrapping = in >>> ETSI M2M. >>> IBAKE is especially suitable in this setting as it is a method that >>> provides mutual authentication and key agreement without the need to >>> rely on third parties such as certificate authorities. >>> So the specific problem that is being solved in ETSI M2M with >> EAP-IBAKE >>> is device bootstrapping that is access network independent. >>>=20 >>> Obviously, as an EAP method EAP-IBAKE can address many other = problems >>> (as numerous other EAP methods can). >>>=20 >>> Regards, >>> -Violeta >>>=20 >>> -----Original Message----- >>> From: Tschofenig, Hannes (NSN - FI/Espoo) >>> [mailto:hannes.tschofenig@nsn.com] >>> Sent: Thursday, January 12, 2012 2:08 AM >>> To: Cakulev, Violeta (Violeta); emu@ietf.org >>> Subject: RE: [Emu] draft-cakulev-emu-eap-ibake >>>=20 >>> Hi Violeta, >>>=20 >>> What problem are you trying to solve with this EAP method? >>>=20 >>> Ciao >>> Hannes >>>=20 >>>> -----Original Message----- >>>> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf >> Of >>>> ext Cakulev, Violeta (Violeta) >>>> Sent: Wednesday, January 11, 2012 10:16 PM >>>> To: emu@ietf.org >>>> Subject: [Emu] draft-cakulev-emu-eap-ibake >>>>=20 >>>> All, >>>> Back in IETF 80 we presented EAP-IBAKE. The link to the I-D is >>> provided >>>> below: >>>> http://tools.ietf.org/html/draft-cakulev-emu-eap-ibake-01 >>>>=20 >>>> This EAP method is based on the Identity-Based Authenticated Key >>>> Exchange (IBAKE) protocol. IBAKE is a protocol for mutual >>>> authentication and key agreement between two or more endpoints. It >> is >>>> based on a public-key based authentication mechanism, where each >>>> message is encrypted with the public key of the corresponding >>> endpoint, >>>> as per the Identity Based Encryption (IBE) principles. As a = result >>> of >>>> the IBAKE protocol, a shared symmetric key is generated by each >>>> endpoint. >>>>=20 >>>> EAP-IBAKE is specified in ETSI TS 102 690 (stage 2) and ETSI TS 102 >>> 921 >>>> (stage 3) as a method for access network independent device and >>> gateway >>>> bootstrapping. >>>> Both specifications are approved and are awaiting publication of >> EAP- >>>> IBAKE (among other things). >>>>=20 >>>> While this document could be of interest to emu WG, it would >> probably >>>> require changes to the WG charter. >>>>=20 >>>> Group's opinion about specifying EAP-IBAKE in emu WG as well as >>>> possible changes to the WG charter is highly appreciated. >>>>=20 >>>> Thanks, >>>> -Violeta >>>> _______________________________________________ >>>> Emu mailing list >>>> Emu@ietf.org >>>> https://www.ietf.org/mailman/listinfo/emu >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >=20