From internet-drafts@ietf.org Thu Feb 7 10:38:16 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C67921F867E; Thu, 7 Feb 2013 10:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh-YaumYH-PT; Thu, 7 Feb 2013 10:38:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348BC21F871D; Thu, 7 Feb 2013 10:38:16 -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: 4.37 Message-ID: <20130207183816.25756.31812.idtracker@ietfa.amsl.com> Date: Thu, 07 Feb 2013 10:38:16 -0800 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-eap-tunnel-method-05.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 18:38:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of the IE= TF. Title : Tunnel EAP Method (TEAP) Version 1 Author(s) : Hao Zhou Nancy Cam-Winget Joseph Salowey Stephen Hanna Filename : draft-ietf-emu-eap-tunnel-method-05.txt Pages : 105 Date : 2013-02-07 Abstract: This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-eap-tunnel-method-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From aland@deployingradius.com Tue Feb 12 12:54:11 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BA821F8BCC for ; Tue, 12 Feb 2013 12:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g79svOoFZjqo for ; Tue, 12 Feb 2013 12:54:11 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 522B021F8BC9 for ; Tue, 12 Feb 2013 12:54:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id A22AE22410A3 for ; Tue, 12 Feb 2013 21:53:38 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF+Bdk7hjNIr for ; Tue, 12 Feb 2013 21:53:36 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121727.dsl.bell.ca [70.26.49.127]) by power.freeradius.org (Postfix) with ESMTPSA id 894A722410A1 for ; Tue, 12 Feb 2013 21:53:36 +0100 (CET) Message-ID: <511AABCF.8020807@deployingradius.com> Date: Tue, 12 Feb 2013 15:53:35 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "emu@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Emu] Last call on draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 20:54:12 -0000 This is a WG last call on the draft-ietf-emu-eap-tunnel-method document. Please post reviews, comments, feedback, etc. to this list. The WG last call will last two weeks, until February 26. If there have been no substantive comments or issues, we will take the document to IETF last call. Minor editorial issues can be resolved then. Alan DeKok. From ietf@augustcellars.com Thu Feb 21 15:24:13 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C6321E8044 for ; Thu, 21 Feb 2013 15:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39cw62ulsGoc for ; Thu, 21 Feb 2013 15:24:12 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8DE21F8443 for ; Thu, 21 Feb 2013 15:24:11 -0800 (PST) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 1499D2CA3A for ; Thu, 21 Feb 2013 15:24:07 -0800 (PST) From: "Jim Schaad" To: References: In-Reply-To: Date: Thu, 21 Feb 2013 15:23:36 -0800 Message-ID: <026e01ce108a$7a575c80$6f061580$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4Qd7MLsLiMgOSbQGyl8oqyFZWyiwAEr+5Q Content-Language: en-us Subject: [Emu] FW: Last call comments on emu-eap-tunnel-method-05 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 23:24:13 -0000 > -----Original Message----- > From: Jim Schaad [mailto:jimsch@augustcellars.com] > Sent: Thursday, February 21, 2013 1:10 PM > To: draft-ietf-emu-eap-tunnel-method@tools.ietf.org > Cc: emu@ietf.org > Subject: Last call comments on emu-eap-tunnel-method-05 > > I have no comments that I would consider to be blocking. There are couple > of issues that should be considered to be dealt with in the last call. > > Jim > > > > 1. Lower case must/may in the document. There are disputes about the role > of a lower case must in a document. Some people consider it to be an RFC > 2119 usage and some people don't. If it is then these all need to be looked > at, if it doesn't then I would suggest putting in text as part of the RFC2119 > boiler plate to say that lower case versions of these words have their natural > language meaning. > > > 2. I am not completely clear on this, but don't know if it needs to be clarified. > Server and client rune one inner EAP method. > Server sends Crypto-Binding TLV and Result TLV Client sends Crypto-Binding > TLV, Request-Action TLV [Negotiate EAP] Server sends EAP-Payload [EAP > start method] Does the server also needs to send an Intermediate-Result > TLV per section 3.3.1? > ---- Note - in section 3.3.3 - it would appear that there is a "may" > recommendation that the server actually send Crypt-Binding TLV, > Intermediate-Result TLV, Result TLV thus making the problem not a problem. > However this is not required behavior. > > 3. Not completely sure the second to last paragraph in 3.3 is correct. Should > the server return the EAP success or failure based on the peer's result TLV or > the peer's request-action tlv? I think that either could be a correct answer I > just want to verify that the text presented is correct. > > 4. Last chance to change our minds and allocate an extra flag in section 4.2.1 > just in case we needed it. I have no idea which is going to be the more scarce > resource. But only one reserve flag might be an issue. > > 5. It is technically incorrect to say that the TLV Type is two octets (section > 4.2.2). I don't know that there is any reason to correct this as it is essentially > correct. Just a we need to be sure we don't want to fix it. (Note: text is > different in section 4.2.2) > > 6. section 4.2.13 - I think that the received version number is supposed to > say "set to the TEAP version number received" not the "EAP version > number" > > 7. section 4.3 s/multiple multiple Basic/multiple Basic/ > > 8. Section 5.2 There are two possible confusions that could result in the > computation of the text string for the IMSK > a) It is possible that the string "\0" could be misinterpreted. This could be > stated as 0x00. > b) It is possible that the 64 could be misinterpreted as being longer than a > byte and thus could be stated as 0x40. (Oops just looked at the referenced > document and it is 0x00 0x40). > Not clear if this really needs to be changed. > > 9. Section 5.2 - s/thendoesn/?????/ > > > > > From jsalowey@cisco.com Fri Feb 22 10:57:40 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECBA21F8CAB for ; Fri, 22 Feb 2013 10:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1xqlL8GwQuR for ; Fri, 22 Feb 2013 10:57:39 -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 8BB0321F8C4C for ; Fri, 22 Feb 2013 10:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=151; q=dns/txt; s=iport; t=1361559459; x=1362769059; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=jssfVUoSYEZK4jOLv/b+UDiiOmYMW7TPM23DbIzpKG4=; b=B0V51C2P+xhBoMADxt/cn12aqUJLd8aHHQTeGB0agBCdNegBcKIntJ4U 6xO2PwpRsowsnNikbAxXnLzfKYQMVbC4EAMWzE0fECJFz1VJr3hNeV0r1 qRNkUxcXwbH+7zY+tROSHbBouy6hBVI7y6NIG3wr7Dx9yhl4bVW6z73Fi s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACC/J1GtJXHB/2dsb2JhbABEvkyCUQmBDBZzgiEBBDpRASoUQicEG4gKni6gbY5dgxdhA6cdgweCJw X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="scan'208";a="180209353" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 22 Feb 2013 18:57:39 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1MIvdDT021366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Feb 2013 18:57:39 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 12:57:39 -0600 From: "Joseph Salowey (jsalowey)" To: "emu@ietf.org" Thread-Topic: Agenda Items for IETF 86 Thread-Index: AQHOES57Akffz72CAU2Pwx5aE83bKA== Date: Fri, 22 Feb 2013 18:57:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.140] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Emu] Agenda Items for IETF 86 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 18:57:40 -0000 The EMU meeting is scheduled for Tuesday March 12, 10:30 - 11:30 Please let the chairs know if you have Items for the agenda.=20 Thanks, Joe From hartmans@mit.edu Fri Feb 22 13:11:51 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7023221E8090 for ; Fri, 22 Feb 2013 13:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.81 X-Spam-Level: X-Spam-Status: No, score=-102.81 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrHzU50QDAsY for ; Fri, 22 Feb 2013 13:11:50 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id E35E321E808C for ; Fri, 22 Feb 2013 13:11:49 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id EC08F20161; Fri, 22 Feb 2013 16:07:04 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D46E9447B; Fri, 22 Feb 2013 16:11:46 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <005001cd9db7$bc8f8230$35ae8690$@augustcellars.com> Date: Fri, 22 Feb 2013 16:11:46 -0500 In-Reply-To: <005001cd9db7$bc8f8230$35ae8690$@augustcellars.com> (Jim Schaad's message of "Fri, 28 Sep 2012 13:27:52 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emu@ietf.org Subject: Re: [Emu] Review - draft-ietf-emu-crypto-bind-00.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 21:11:51 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> As was pointed out to me, the subject message on the message Jim> had the wrong draft name (even if the version number was Jim> right). Thanks for the review. I've addressed all the comments except: 1) I'm asking a co-author to help with your recommendations about ascii-art 2) >> 5. In section 3.2.2 - Item #1 seems to be a hardship to get >> implemented Jim> and >> get right. There is an easy argument that servers can have a >> policy configured about what inner methods can be used, but >> imposing it on the peer and making the configuration be server >> based can be problematic. I think that this issue probably >> deserves more text. How is the Jim> configuration >> updated and transferred to the peer. The list of bullets is at the end of the section in a "recap". I did add a sentence to the paragraph about peer policy pointing out that it's difficult to configure this policy. The difficulty of this sort of peer configuration is one of the main reasons I think EMSK-based cryptographic binding is important. So, I don't have any good answers. I don't think making the configuration server-based is particularly tricky; I think getting any EAP configuration at all beyond the minimal to get things working to the peer is the hard part. I'd ex pect most peers only interact with one EAP server. Even when peers interact with multiple EAP servers the configuration already tends to be server specific. >> >> 6. In section 3.2.4 - "then condition 3" need to tell me where >> condition Jim> 3 is - >> what section? There's now a parenthetical defining condition 3; all the numbered conditions are references back to 3.1. I think with the parenthetical added the text is clear without adding a section 3.1 reference to each numbered condition. >> >> 8. In section 3.3 - can the intended intermediary be on the >> other side - Jim> that is >> between the NAS and the authenticator rather than the peer and >> the NAS? This is not clear from the text It's always between the NAS and the home server. Added clarification sentence. From hartmans@mit.edu Fri Feb 22 15:19:24 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA0E21E808C for ; Fri, 22 Feb 2013 15:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDvTeRjdcRnI for ; Fri, 22 Feb 2013 15:19:23 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 86AFD21E8049 for ; Fri, 22 Feb 2013 15:19:19 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 395F920161; Fri, 22 Feb 2013 18:14:34 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1AB8E447B; Fri, 22 Feb 2013 18:19:16 -0500 (EST) From: Sam Hartman To: emu@ietf.org,draft-ietf-emu-crypto-binding@tools.ietf.org Date: Fri, 22 Feb 2013 18:19:16 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Emu] crypto binding: why did I want a survey of methods X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 23:19:24 -0000 So, the current crypto binding draft has empty sections for a survey of tunnel methods and a survey of inner methods. Does anyone have an idea what was going to go in those sections? I'm guessing I put those section headers there, but I cannot remember what I was going to survey for. If there's something we want to collect about methods I'm happy to do it. Otherwise, though, I'd prefer to drop the sections. From hartmans@mit.edu Fri Feb 22 15:23:08 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F85C21E808E for ; Fri, 22 Feb 2013 15:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpqqHy7k2BoR for ; Fri, 22 Feb 2013 15:23:08 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 056AB21E808C for ; Fri, 22 Feb 2013 15:23:07 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 2C3F220161; Fri, 22 Feb 2013 18:18:23 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 07B7F447B; Fri, 22 Feb 2013 18:23:05 -0500 (EST) From: Sam Hartman To: emu@ietf.org,draft-ietf-emu-crypto-bind@tools.ietf.org Date: Fri, 22 Feb 2013 18:19:16 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Emu] crypto binding: why did I want a survey of methods X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 23:23:08 -0000 So, the current crypto binding draft has empty sections for a survey of tunnel methods and a survey of inner methods. Does anyone have an idea what was going to go in those sections? I'm guessing I put those section headers there, but I cannot remember what I was going to survey for. If there's something we want to collect about methods I'm happy to do it. Otherwise, though, I'd prefer to drop the sections. From ietf@augustcellars.com Fri Feb 22 21:18:19 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A1D21E8053 for ; Fri, 22 Feb 2013 21:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wtQEZkA9b6Z for ; Fri, 22 Feb 2013 21:18:18 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id DDC9721E8050 for ; Fri, 22 Feb 2013 21:18:18 -0800 (PST) Received: from Philemon (50-39-222-11.bvtn.or.frontiernet.net [50.39.222.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 9CF292CA00; Fri, 22 Feb 2013 21:18:18 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" , , References: In-Reply-To: Date: Fri, 22 Feb 2013 21:17:48 -0800 Message-ID: <007c01ce1185$1f46a890$5dd3f9b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMrSgD1lRu1hEo5/aw5Z5fI/5nqz5XMdZ0w Content-Language: en-us Subject: Re: [Emu] crypto binding: why did I want a survey of methods 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: Sat, 23 Feb 2013 05:18:19 -0000 Sam, I made an assumption you were going to do a survey of the existing EAP methods and compare them against a set of criteria that the document has outlined. As an example: outer EAP methods should 1) have channel binding, 2) should talk about TLS certificate naming, 3) setup for mixing key material Inner EAP methods need to produce MSKs or EMSKs and maybe do other things. This gives a quick overview for selection by people of which methods you believe will deal with the problems outlined in this document and which do not and why. Jim > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Sam Hartman > Sent: Friday, February 22, 2013 3:19 PM > To: emu@ietf.org; draft-ietf-emu-crypto-binding@tools.ietf.org > Subject: [Emu] crypto binding: why did I want a survey of methods > > > So, the current crypto binding draft has empty sections for a survey of tunnel > methods and a survey of inner methods. > > Does anyone have an idea what was going to go in those sections? I'm > guessing I put those section headers there, but I cannot remember what I > was going to survey for. > > If there's something we want to collect about methods I'm happy to do it. > Otherwise, though, I'd prefer to drop the sections. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Sat Feb 23 17:46:58 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4AC21F8F73 for ; Sat, 23 Feb 2013 17:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.789 X-Spam-Level: X-Spam-Status: No, score=-102.789 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbUVhONlikDu for ; Sat, 23 Feb 2013 17:46:57 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9C921F8F63 for ; Sat, 23 Feb 2013 17:46:57 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 6141A20180 for ; Sat, 23 Feb 2013 20:42:09 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B83C7447B; Sat, 23 Feb 2013 20:46:46 -0500 (EST) From: Sam Hartman To: emu@ietf.org Date: Sat, 23 Feb 2013 20:46:46 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Emu] Comments on draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 01:46:58 -0000 First, the document has been improved a lot in its clarity since the last time I read it. I'd really like to thank the editors, Jim and everyone else who gave comments for some excellent work. TEAP is by far the best EAP method I've ever reviewed, and I think security of EAP conversations would be significantly improved if people implement and deploy TEAP. Section 3.4: Does the server_id depend on whether the identifier is actually authenticated? That is, let's say the server is using a certificate but the client has no way to validate the certificate back to a trust anchor. However, the client uses some strong inner method and EMSK-based crypto binding to verify the server. Does the subject from the server cert make its way into the server ID in this case? Is it important that implementations get binary identical strings for server_id on both sides of the conversation? I think the text in 3.4 is sufficient that you'd get the right security properties out of the identity, but I suspect different implementations could get slightly different encoding etc. I have never used peer id, server id or session id, so I'm not sure if anyone cares about that. 3.5: old: tls_unique = tls_unique for the phase 1 outer tunnel as defined by [RFC5929]. new: tls_unique = tls_unique for the phase 1 outer tunnel at the beginning of phase 2 as defined by section 3.1 of [RFC5929]. rationale: The quantity described in section 3.1 of rfc 5929 can change when there is TLS renegotiation. This should avoid that. Section 3.8-3.10: All of these sections involve peer services in the terms of draft-ietf-abfabf-emu-crypto-bind. I believe the advice in section 4.2 of draft-ietf-emu-crypto-bind applies quite strongly here. In particular, the peer MUST track whether it has authenticated the server. There's text repeated at various points in the TEAP spec that tries to say this, including some text in 3.8 and a hint at 3.10. I think this needs to be more unified. In particular I propose that: * A new section 3.11 titled "Mutual Authentication for Peer Services" be added: Several TEAP services including server unauthenticated provisioning, PAC provisioning, certificate provisioning and channel binding depend on the peer trusting the TEAP server. Peers need to mutually authenticate the server before these peer services are used. TEAP peers MUST track whether mutual authentication has taken place. Mutual authentication results if the peer trusts the provided server certificate belongs to the server; typically this involves both validating the certificate to a trust anchor andconfirming the entity named by the certificate is the intended server. Mutual authentication also results when the procedures of section 3.3 are used to resume a session in which the server was previously mutually authenticated. Alternatively, if an inner EAP method providing mutual authentication and an Extended Master Session Key (EMSK) is executed and cryptographic binding with the EMSK compound MAC present (section 4.2.13), then the session is mutually authenticated and peer services can be used. TEAP implementations SHOULD Not use peer services by default unless the session is mutually authenticated. TEAP implementations SHOULD have a configuration where authentication fails if mutual authentication cannot be achieved. An additional complication arises when a tunnel method authenticates multiple parties such as authenticating both the peer machine and the peer user to the EAP server. Depending on how mutual authentication is achieved, only some of these parties may have confidence in it. For example if a strong shared secret is used to mutually authenticate the user and the EAP server, the machine may not have confidence that the EAP server is the authenticated party if the machine cannot trust the user not to disclose the shared secret to an attacker. In these cases, the parties who have achieved mutual authentication need to be considered when evaluating whether to use peer services. * Section 3.8-3.10 explicitly refer to this new section. Some of the text about server authentication already present in these sections can be removed. * The channel binding TLV and the request-action TLV should also refer to 3.11. Section 4.2.7: Replace the definition of data with The data field contains a channel-binding message as defined in section 5.3 of RFC 6677. Will the channel binding data (client to server) ever be outside of a request-action TLV? If not, it's probably worth pointing this out. There doesn't seem to be a way for a server to request channel binding. If that's true we should probably add the following: Since a server cannot indicate a desire for channel binding, clients that have channel binding data to send SHOULD include channel-binding TLV in a request-action TLV if mutual authentication (section 3.11) succeeded. section 7.3: Please update references to draft-hartman-emu-mulutal-crypto-bind to draft-ietf-emu-mutual-crypto-bind section 7.6: Replace peer MUST validate with peer SHOULD validate. 3.10 is an example where the peer SHOULDN't validate, and no one is going to make that a MUST so let's not lie. I'd also like to see the requirement for implementations to support matching the realm of a NAI against a dns name in the subjectAltName to be a MUST not a SHOULD. I think we have strong evidence that we need an interoperable way to name EAP servers. Note that's MUST implement, not MUSt use. --Sam From hartmans@mit.edu Sun Feb 24 10:56:41 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021BD21F90A2 for ; Sun, 24 Feb 2013 10:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.773 X-Spam-Level: X-Spam-Status: No, score=-102.773 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8la0SoqMrkF for ; Sun, 24 Feb 2013 10:56:40 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id EDF8321F90A1 for ; Sun, 24 Feb 2013 10:56:38 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id A7EA42010D; Sun, 24 Feb 2013 13:51:49 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 43BD0447B; Sun, 24 Feb 2013 13:56:27 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <007c01ce1185$1f46a890$5dd3f9b0$@augustcellars.com> Date: Sun, 24 Feb 2013 13:56:27 -0500 In-Reply-To: <007c01ce1185$1f46a890$5dd3f9b0$@augustcellars.com> (Jim Schaad's message of "Fri, 22 Feb 2013 21:17:48 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 'Sam Hartman' , emu@ietf.org, draft-ietf-emu-crypto-binding@tools.ietf.org Subject: Re: [Emu] crypto binding: why did I want a survey of methods 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, 24 Feb 2013 18:56:41 -0000 Hi. I've included a survey of tunnel methods that have made it to RFC and TEAP. It's quite possible that people want to cover more tunnel methods in the summary (LEAP, PEAP, EAP-TTLS v1). People who want to supply text are welcome to do so. After looking at it, I don't feel comfortable volunteering to do the inner method summary. For the more modern methods the answer tends to always be "yeah, nothing wrong there." Now, the method itself may be weaker than you'd like, but the mutual authentication and key handling tends not to be of particular note. At least that seems to be true for the PAKE methods, for GPSK and for revised AKA. Note that is an initial guess, I don't have enough confidence in that statement to go write it down in the draft, and I'm not convinced it's all that useful. As you get into older methods, say EAP-SIM and EAP-MSCHAPV2, it gets more complex. EAP-SIM has some significant challenges with mutual authentication and I think with key generation. Being able to summary more than what is in the eap-sim security considerations section would involve a lot more operational knowledge than I have. I don't even know where to find documentation for EAP-MSCHAPv2. I'm strongly suspecting it's got problems, given its age and attachment to md4 and rc4. However, the mschapv2 PPP extensions got away with a one sentence security considerations section, so it's definitely not just summarizing already current security analysis. So, I don't think what I could do with inner method surveys is going to be helpful enough to write up. I'm dropping that section but if text emerges within the WG I'd be happy to include it. I think though that we're doing a good enough job with security considerations sections for post-RFC 3748 EAp inner methods that we don't need such a summary. From ietf@augustcellars.com Sun Feb 24 13:46:59 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32CF21F911F for ; Sun, 24 Feb 2013 13:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fkapK0uD96D for ; Sun, 24 Feb 2013 13:46:58 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2C521F911B for ; Sun, 24 Feb 2013 13:46:58 -0800 (PST) Received: from Philemon (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id E44442C9F4; Sun, 24 Feb 2013 13:46:57 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" References: <007c01ce1185$1f46a890$5dd3f9b0$@augustcellars.com> In-Reply-To: Date: Sun, 24 Feb 2013 13:46:27 -0800 Message-ID: <004c01ce12d8$6670d6b0$33528410$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMrSgD1lRu1hEo5/aw5Z5fI/5nqzwC+O+68AgjWO8mVuONwEA== Content-Language: en-us Cc: emu@ietf.org, draft-ietf-emu-crypto-binding@tools.ietf.org Subject: Re: [Emu] crypto binding: why did I want a survey of methods 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, 24 Feb 2013 21:46:59 -0000 Sam, I think it would be useful to do a partial survey and just say that it is a partial survey. In part I think this would be useful just so that the points that you feel are important for the CB are highlighted. I would be perfectly willing for such a survey to cover only a couple of the most recent EAP methods with a statement that it is a partial survey and stating why. However I can also understand why you would not want to do this because I would be afraid that the IESG would want to know why it is not a more complete survey. Jim > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Sunday, February 24, 2013 10:56 AM > To: Jim Schaad > Cc: 'Sam Hartman'; emu@ietf.org; draft-ietf-emu-crypto- > binding@tools.ietf.org > Subject: Re: [Emu] crypto binding: why did I want a survey of methods > > Hi. I've included a survey of tunnel methods that have made it to RFC and > TEAP. It's quite possible that people want to cover more tunnel methods in > the summary (LEAP, PEAP, EAP-TTLS v1). > People who want to supply text are welcome to do so. > > After looking at it, I don't feel comfortable volunteering to do the inner > method summary. For the more modern methods the answer tends to > always be "yeah, nothing wrong there." Now, the method itself may be > weaker than you'd like, but the mutual authentication and key handling > tends not to be of particular note. At least that seems to be true for the > PAKE methods, for GPSK and for revised AKA. Note that is an initial guess, I > don't have enough confidence in that statement to go write it down in the > draft, and I'm not convinced it's all that useful. > > As you get into older methods, say EAP-SIM and EAP-MSCHAPV2, it gets > more complex. EAP-SIM has some significant challenges with mutual > authentication and I think with key generation. Being able to summary more > than what is in the eap-sim security considerations section would involve a > lot more operational knowledge than I have. > > I don't even know where to find documentation for EAP-MSCHAPv2. I'm > strongly suspecting it's got problems, given its age and attachment to > md4 and rc4. However, the mschapv2 PPP extensions got away with a one > sentence security considerations section, so it's definitely not just > summarizing already current security analysis. > > So, I don't think what I could do with inner method surveys is going to be > helpful enough to write up. > > I'm dropping that section but if text emerges within the WG I'd be happy to > include it. > I think though that we're doing a good enough job with security > considerations sections for post-RFC 3748 EAp inner methods that we don't > need such a summary. From internet-drafts@ietf.org Mon Feb 25 07:14:59 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CF721F9489; Mon, 25 Feb 2013 07:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dF-QbGhgJVWC; Mon, 25 Feb 2013 07:14:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7456021F94A0; Mon, 25 Feb 2013 07:14:44 -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: 4.40 Message-ID: <20130225151444.30229.57751.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 07:14:44 -0800 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-crypto-bind-02.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:14:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of the IE= TF. Title : EAP Mutual Cryptographic Binding Author(s) : Sam Hartman Margaret Wasserman Dacheng Zhang Filename : draft-ietf-emu-crypto-bind-02.txt Pages : 25 Date : 2013-02-25 Abstract: As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. [RFC 3748] is a facility that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in- the-middle attacks and recommends mutual cryptographic binding, a new form of cryptographic binding that protects both peer and server along with other mitigations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-emu-crypto-bind-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-crypto-bind-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@mit.edu Mon Feb 25 13:36:04 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F98321E80E9 for ; Mon, 25 Feb 2013 13:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.759 X-Spam-Level: X-Spam-Status: No, score=-102.759 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlpBFQtgVkhL for ; Mon, 25 Feb 2013 13:36:03 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 39AB721E80DA for ; Mon, 25 Feb 2013 13:36:03 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 0B98620118 for ; Mon, 25 Feb 2013 16:31:12 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6C75B447B; Mon, 25 Feb 2013 16:36:02 -0500 (EST) From: Sam Hartman To: emu@ietf.org Date: Mon, 25 Feb 2013 16:36:02 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Emu] I think draft-ietf-emu-crypto-bind is ready for last call X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 21:36:04 -0000 There's an outstanding comment asking for a change to the ascii art. Besides that I believe we've addressed the comments and generally improved the draft. I think it's ready for last call. I do suspect we'll collect some more comments and have some clarifications after last call, but I suspect last call is the best way to collect those. From ietf@augustcellars.com Wed Feb 27 19:29:37 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDB221F8A11 for ; Wed, 27 Feb 2013 19:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+QuA4BnT+gO for ; Wed, 27 Feb 2013 19:29:36 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 67D3921F8A0C for ; Wed, 27 Feb 2013 19:29:36 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id CB4A638F10 for ; Wed, 27 Feb 2013 19:29:35 -0800 (PST) From: "Jim Schaad" To: References: In-Reply-To: Date: Wed, 27 Feb 2013 19:29:02 -0800 Message-ID: <029101ce1563$c2e5f8c0$48b1ea40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4VO663AM5B3wgSS92EnRELKs5ZggAKAyHg Content-Language: en-us Subject: [Emu] FW: Comments on draft-ietf-emu-crypto-bind-02 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, 28 Feb 2013 03:29:37 -0000 > -----Original Message----- > From: Jim Schaad [mailto:jimsch@augustcellars.com] > Sent: Wednesday, February 27, 2013 5:47 PM > To: 'draft-ietf-emu-crypto-bind@tools.ietf.org' > Cc: emu@ietf.org > Subject: Comments on draft-ietf-emu-crypto-bind-02 > > Sam et al, > > You said you thought you were ready for a WGLC so I did a much more > detailed review. Lots of little things but nothing that should stop a WGLC in > my opinion. > > > 1. Keywords text should be attached to the first section of the document > and not to the abstract. > > 2. In the abstract, please keep some type of name (such as EAP) with the > RFC reference. If this text was standalone the reference would not really > work and people would not really know what the RFC was about. > > 3. I-D.ietf-emu-eap-tunnel-req has been published as RFC 6678 and the > reference should be updated. > > 4. Section #1 paragraph #3 > OLD: > An > example of the attack can happen when a peer is willing to perform > authentication inside and outside a tunnel. > NEW: > An example of the attack can happen when a peer is willing to use the same > EAP method to perform authentication inside and outside of a tunnel. > > After all, the tunnel is a method of authentication. > > 5. On the ASCII art - I could clean this up between now and the next IETF if > neither of your co-authors are willing to do so. > > 6. Section #1 last paragraph. I am not sure that it is sufficient for the server > to have this policy by itself. It is necessary that both the server and the peer > have the common policy and enforce it. In this case the server may only be > offering the inner method inside of the tunnel but if the peer will allow it to > be run outside of the tunnel it does not matter. > > 7. Section #2 para #1 - Prior to channel bindings, peers could not > distinguish one Network Access Service (NAS) from another, so attacks > where one NAS impersonated another were out-of-scope. > > I suggest s/distinguish/reliably distinguish/ > > 8. In section #3 para #1 - This sentence exists In this attack, one party adds a > layer of tunneling such > that from the perspective of the EAP peer, there are more methods > than from the perspective of the EAP server. > > I don't understand the intent of the sentence. From the example above > there was no additional EAP methods being added that I could see. I can see > the addition of the tunneling, but it is not clear why there are more methods > > 9. In section 3.2.1 - Potental additional challenge to be added to para #2 > It is not always obvious that a provided certificate is intended for EAP tunnel > authentication rather than for some other purpose (such as doing HTTP over > TLS). > > 10. In section 3.2.1 - Counter argument on section #3 should be added: > > On the other hand, not using commercial CAs can be problematic for users > who are trying to use kiosk type access points. Users may be able to > remember a user name and a password but are probably not going to be able > to correctly provide the necessary validation information for a private CA. > The use of commercial CAs in this case is also problematic as the user will > probably not be able to provide the machine name of the tunnel provider > either. > > 11. Comment " Please view in a fixed-width font such as Courier." Should be > removed > > 12. Section 3.2.2 - I think that the conversion of EAP methods is sufficiently > significant that it merits it's own section in the text. Where it is does not > make it follow nicely. Not sure why it is under server policy rather than > standing on its own. > > 13. Section 3.2.3 - The last sentence should say "when the inner method is a > key deriving EAP method". > > 14. Section 3.2.4 - Current text is "insert intermediates between the peer > and the EAP server." As the NAS sits between the peer and the EAP server > this is not a reasonable statement. I might try "split the EAP server into the > tunnel EAP server and the inner EAP server(s)." > > 15. Section 3.2.4 - In point #3 - does it need to depend on the MSK and the > EMSK or only on the EMSK? TEAP will depend on only the EMSK and not the > MSK if one is available and usable. > > 16. Section 3.2.4 - Given the text "If EMSK-based cryptographic binding is an > optional facility, the > negotiation of whether to use it MUST be protected by the inner MSK > or EMSK." > a) I don't understand the requirement > b) Do you believe that TEAP meets this requirement? > If I understand the sentence correctly I believe that TEAP does not meet this > requirement as the negotiation would be fully available to anyone who could > get into the tunnel. However the negotiation is protected by the tunnel > itself. > > 17. Section 6 - I don't really care for the security considerations at present. > > It seem to be rather perfunctorily written. Minimum things that I think I > would include here > > Traditionally, the primary focus of EAP has been to authenticate a peer to a > server in order to allow access to a network. With the advent of other types > of NAS services, such as are provide by ABFAB, it becomes more important > that the EAP peer be able to get information from the EAP server about the > network and its environments. This imposes new security requirements on > the EAP protocol such as a need for mutual authentication and a stronger > need to prevent MITM attacks on the authentication. > > This memo presents some of the attacks that are possible and provides a > number of recommendations for operators and protocol developers to > follow in order to prevent the attacks presented. The most significant of > these are to use tunnel methods and to use appropriate channel binding > methods within the tunnel methods. > > 18. Section 7 - review for additional people you might want to acknowledge. > Also - capitalize Margaret. > > Jim From ietf@augustcellars.com Wed Feb 27 19:39:58 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B4F21F86FB for ; Wed, 27 Feb 2013 19:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olnjxwtL3oXB for ; Wed, 27 Feb 2013 19:39:58 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id D168621F86B6 for ; Wed, 27 Feb 2013 19:39:54 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 8787338F09; Wed, 27 Feb 2013 19:39:52 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" , References: In-Reply-To: Date: Wed, 27 Feb 2013 19:39:18 -0800 Message-ID: <029201ce1565$32d03870$9870a950$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIuxCl7T2T4S0PLy9RRXTXiFJBVMZfNP6Fg Content-Language: en-us Subject: Re: [Emu] Comments on draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 03:39:58 -0000 Sam, My responses are inline. May not agree with the authors however. Jim > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Sam Hartman > Sent: Saturday, February 23, 2013 5:47 PM > To: emu@ietf.org > Subject: [Emu] Comments on draft-ietf-emu-eap-tunnel-method > > > > First, the document has been improved a lot in its clarity since the last time I > read it. I'd really like to thank the editors, Jim and everyone else who gave > comments for some excellent work. > > > TEAP is by far the best EAP method I've ever reviewed, and I think security of > EAP conversations would be significantly improved if people implement and > deploy TEAP. > > Section 3.4: > > Does the server_id depend on whether the identifier is actually > authenticated? > That is, let's say the server is using a certificate but the client has no way to > validate the certificate back to a trust anchor. > However, the client uses some strong inner method and EMSK-based crypto > binding to verify the server. > Does the subject from the server cert make its way into the server ID in this > case? > > Is it important that implementations get binary identical strings for server_id > on both sides of the conversation? > I think the text in 3.4 is sufficient that you'd get the right security properties > out of the identity, but I suspect different implementations could get slightly > different encoding etc. > I have never used peer id, server id or session id, so I'm not sure if anyone > cares about that. I would expect that the id from the certificate would be returned if the inner method provided mutual authentication and the crypto bindings were successful. At that point one would have a statement about the certificate that says it matches that of any server id stated inside of the tunnel. The certificate would be the one presented by the certificate - could not change without TLS failing. The channel binding would give you validation of the tunnel and mutual auth would give you validation of the server. I don't know what it would be to have binary identical strings on both sides. Only the peer side would get server ids and only the server side would get peer ids. As with you I have never used the ids - so I would not know what they are used for in general either. > 3.5: > > old: > tls_unique = tls_unique for the phase 1 outer tunnel as defined by > [RFC5929]. > > new: > tls_unique = tls_unique for the phase 1 outer tunnel at the > beginning of phase 2 as defined by section 3.1 of [RFC5929]. > > > rationale: The quantity described in section 3.1 of rfc 5929 can change when > there is TLS renegotiation. > This should avoid that. > Section 3.8-3.10: This is a reasonable change. > All of these sections involve peer services in the terms of draft-ietf-abfabf- > emu-crypto-bind. > I believe the advice in section 4.2 of draft-ietf-emu-crypto-bind applies quite > strongly here. > In particular, the peer MUST track whether it has authenticated the server. > > There's text repeated at various points in the TEAP spec that tries to say this, > including some text in 3.8 and a hint at 3.10. > > I think this needs to be more unified. > In particular I propose that: > > * A new section 3.11 titled "Mutual Authentication for Peer Services" be > added: > > > Several TEAP services including server unauthenticated provisioning, PAC > provisioning, certificate provisioning and channel binding depend on the peer > trusting the TEAP server. Peers need to mutually authenticate the server > before these peer services are used. > > TEAP peers MUST track whether mutual authentication has taken place. > Mutual authentication results if the peer trusts the provided server > certificate belongs to the server; typically this involves both validating the > certificate to a trust anchor andconfirming the entity named by the certificate > is the intended server. Mutual authentication also results when the > procedures of section 3.3 are used to resume a session in which the server > was previously mutually authenticated. Alternatively, if an inner EAP method > providing mutual authentication and an Extended Master Session Key > (EMSK) is executed and cryptographic binding with the EMSK compound > MAC present (section 4.2.13), then the session is mutually authenticated and > peer services can be used. TEAP implementations SHOULD Not use peer > services by default unless the session is mutually authenticated. TEAP > implementations SHOULD have a configuration where authentication fails if > mutual authentication cannot be achieved. > > An additional complication arises when a tunnel method authenticates > multiple parties such as authenticating both the peer machine and the peer > user to the EAP server. Depending on how mutual authentication is > achieved, only some of these parties may have confidence in it. For example > if a strong shared secret is used to mutually authenticate the user and the > EAP server, the machine may not have confidence that the EAP server is the > authenticated party if the machine cannot trust the user not to disclose the > shared secret to an attacker. In these cases, the parties who have achieved > mutual authentication need to be considered when evaluating whether to > use peer services. > > > * Section 3.8-3.10 explicitly refer to this new section. Some of the > text about server authentication already present in these sections can > be removed. > > * The channel binding TLV and the request-action TLV should also refer > to 3.11. > > Section 4.2.7: > > Replace the definition of data with > > The data field contains a channel-binding message as defined in section > 5.3 of RFC 6677. > > Will the channel binding data (client to server) ever be outside of a request- > action TLV? > If not, it's probably worth pointing this out. > > There doesn't seem to be a way for a server to request channel binding. > If that's true we should probably add the following: > Since a server cannot indicate a desire for channel binding, clients that have > channel binding data to send SHOULD include channel-binding TLV in a > request-action TLV if mutual authentication (section 3.11) succeeded. If this is true - then I agree it is a flaw. I think that one could send a channel-binding TLV with no data to request that a client send channel binding data back. This should not cause any significant problems. One could then have Channel-binding server->peer - no data Channel-binding peer->server - here is my data Channel-binding server->peer - here is my data However I believe that the client can initiate this by just sending the channel binding TLV in the clear and not in a request if the client wants to initiate it. > > section 7.3: > Please update references to draft-hartman-emu-mulutal-crypto-bind to > draft-ietf-emu-mutual-crypto-bind > > > section 7.6: > > Replace peer MUST validate with peer SHOULD validate. 3.10 is an example > where the peer SHOULDN't validate, and no one is going to make that a > MUST so let's not lie. I'd also like to see the requirement for > implementations to support matching the realm of a NAI against a dns name > in the subjectAltName to be a MUST not a SHOULD. I think we have strong > evidence that we need an interoperable way to name EAP servers. > Note that's MUST implement, not MUSt use. > > --Sam > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From aland@deployingradius.com Thu Feb 28 06:29:02 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E148521F8B2F for ; Thu, 28 Feb 2013 06:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ath7EHOypI6B for ; Thu, 28 Feb 2013 06:28:57 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5F721F84D9 for ; Thu, 28 Feb 2013 06:28:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 26FAD2240F31 for ; Wed, 27 Feb 2013 17:12:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCrC3Y3MHkWv for ; Wed, 27 Feb 2013 17:12:32 +0100 (CET) Received: from Thor-2.local (unknown [216.16.250.138]) by power.freeradius.org (Postfix) with ESMTPSA id BD88622403DE for ; Wed, 27 Feb 2013 17:12:32 +0100 (CET) Message-ID: <512E306F.7060205@deployingradius.com> Date: Wed, 27 Feb 2013 11:12:31 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "emu@ietf.org" References: <511AABCF.8020807@deployingradius.com> In-Reply-To: <511AABCF.8020807@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Emu] Last call on draft-ietf-emu-eap-tunnel-method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 14:29:02 -0000 Alan DeKok wrote: > This is a WG last call on the draft-ietf-emu-eap-tunnel-method > document. Please post reviews, comments, feedback, etc. to this list. > > The WG last call will last two weeks, until February 26. > > If there have been no substantive comments or issues, we will take the > document to IETF last call. Minor editorial issues can be resolved then. > There have been no comments during the last call period. We can therefore close the WG last call, and move the document on to the next step. Alan DeKok.