From aland@deployingradius.com Tue Sep 25 08:04: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 214F51F0C92 for ; Tue, 25 Sep 2012 08:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syGWYsieri+Z for ; Tue, 25 Sep 2012 08:04:17 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C28A1F040A for ; Tue, 25 Sep 2012 08:04:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 12B4522439F9 for ; Tue, 25 Sep 2012 17:04:15 +0200 (CEST) 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 qq8QYUGcxFja for ; Tue, 25 Sep 2012 17:04:12 +0200 (CEST) Received: from Thor.local (pas38-7-83-153-93-21.fbx.proxad.net [83.153.93.21]) by power.freeradius.org (Postfix) with ESMTPSA id A66372240BB3 for ; Tue, 25 Sep 2012 17:04:12 +0200 (CEST) Message-ID: <5061C7EC.8010807@deployingradius.com> Date: Tue, 25 Sep 2012 17:04:12 +0200 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] Looking for reviewers 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, 25 Sep 2012 15:04:18 -0000 We'd like to get the final two documents into last call before the next meeting. Therefore, we're looking for reviewers: https://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ Please post reviews to the list. If all goes well, we can get updated documents issued before the next meeting. Thanks to everyone for their help. Alan DeKok. From simon@josefsson.org Tue Sep 25 11:02:25 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 61D2121F884F for ; Tue, 25 Sep 2012 11:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.874 X-Spam-Level: X-Spam-Status: No, score=-99.874 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, 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 EVgAtHRvCcvP for ; Tue, 25 Sep 2012 11:02:25 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0DC21F8816 for ; Tue, 25 Sep 2012 11:02:23 -0700 (PDT) Received: from latte (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q8PI2H8o018873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 25 Sep 2012 20:02:18 +0200 From: Simon Josefsson To: "emu\@ietf.org" References: <5061C7EC.8010807@deployingradius.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120925:emu@ietf.org::0KqU5VK3L9ej+3pH:RjrJ X-Hashcash: 1:22:120925:aland@deployingradius.com::Z4Pi0/fgSf5bEwxW:LTCo Date: Tue, 25 Sep 2012 20:02:16 +0200 In-Reply-To: <5061C7EC.8010807@deployingradius.com> (Alan DeKok's message of "Tue, 25 Sep 2012 17:04:12 +0200") Message-ID: <8739267zh3.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Subject: Re: [Emu] Looking for reviewers 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, 25 Sep 2012 18:02:25 -0000 Alan DeKok writes: > https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ Section 5.3: The Compound MAC computation is as follows: CMK = CMK[j] Compound-MAC = HMAC-HASH( CMK, BUFFER ) where j is the number of the last successfully executed inner EAP method, HASH is the default hash function or the alternative hash function negotiated in TLS 1.2 [RFC5246], and BUFFER is created after concatenating these fields in the following order: TLS may negotiate MACs that are not based on HMAC. Am I missing some context here, or should this really be something like: The Compound MAC computation is as follows: CMK = CMK[j] Compound-MAC = MAC( CMK, BUFFER ) where j is the number of the last successfully executed inner EAP method, MAC is the MAC function negotiated via TLS 1.2 [RFC5246], and BUFFER is created after concatenating these fields in the following order: Section 5.1: derivation is "teap seesion key seed". The length of the session key Is this typo intentional? I see it repeated in the IANA considerations as well. /Simon From hzhou@cisco.com Tue Sep 25 11:55: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 06B0621F87D7 for ; Tue, 25 Sep 2012 11:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 IhvVToUVuvt9 for ; Tue, 25 Sep 2012 11:55:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7710921F87D6 for ; Tue, 25 Sep 2012 11:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1507; q=dns/txt; s=iport; t=1348599349; x=1349808949; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=OyJCeaDTNrrkSAbsgoiYE3PePlIXNXBsU6aTudOWBW0=; b=Ijc0JDctkXdtjlnJ8G8Tl6ZWfRGxOqIvIQapQjfrH28Jm6hJlRRQymw1 EWX/RliDQxyel9CSTEeqE+CJbQ/l1B6YZ+j9joEw0+mSIb37JNlMIfZZj EeCaUxWDulOFAe/9riowtjs8ZoWVDfWIVwzepHOhxkyOaZc/3plJgrE2q o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAK78YVCtJXG9/2dsb2JhbABFvmWBCIIiAQQBAQEPASc0HQEINjcLJQIEARIih2MLmRWPVpBrBJFcA5I1gzGOP4FpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,484,1344211200"; d="scan'208";a="125205384" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 25 Sep 2012 18:55:49 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8PItmXh001830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Sep 2012 18:55:48 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Tue, 25 Sep 2012 13:55:48 -0500 From: "Hao Zhou (hzhou)" To: Simon Josefsson , "emu@ietf.org" Thread-Topic: [Emu] Looking for reviewers Thread-Index: AQHNmy8Mk+bWhmFOD06VL7lBcSZhJJebWX7qgAAfpoA= Date: Tue, 25 Sep 2012 18:55:48 +0000 Message-ID: In-Reply-To: <8739267zh3.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [64.101.219.104] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19208.004 x-tm-as-result: No--34.203900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <986F74BD5AF73F448AB734E890DC210A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Emu] Looking for reviewers 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, 25 Sep 2012 18:55:50 -0000 Simon: Thanks for the review. Good catch on both. We will fix both of them. On 9/25/12 2:02 PM, "Simon Josefsson" wrote: >Alan DeKok writes: > >> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ > >Section 5.3: > > The Compound MAC computation is as follows: > > CMK =3D CMK[j] > Compound-MAC =3D HMAC-HASH( CMK, BUFFER ) > > where j is the number of the last successfully executed inner EAP > method, HASH is the default hash function or the alternative hash > function negotiated in TLS 1.2 [RFC5246], and BUFFER is created after > concatenating these fields in the following order: > >TLS may negotiate MACs that are not based on HMAC. Am I missing some >context here, or should this really be something like: > > The Compound MAC computation is as follows: > > CMK =3D CMK[j] > Compound-MAC =3D MAC( CMK, BUFFER ) > > where j is the number of the last successfully executed inner EAP > method, MAC is the MAC function negotiated via TLS 1.2 [RFC5246], and > BUFFER is created after concatenating these fields in the following > order: > >Section 5.1: > > derivation is "teap seesion key seed". The length of the session key > >Is this typo intentional? I see it repeated in the IANA considerations >as well. > >/Simon >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www.ietf.org/mailman/listinfo/emu From ietf@augustcellars.com Tue Sep 25 21:12:06 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 888AD1F0CE9 for ; Tue, 25 Sep 2012 21:12:06 -0700 (PDT) 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 olXcza33safX for ; Tue, 25 Sep 2012 21:12:06 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED78D1F0CB8 for ; Tue, 25 Sep 2012 21:12:05 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 304952C9BE for ; Tue, 25 Sep 2012 21:12:05 -0700 (PDT) From: "Jim Schaad" To: Date: Tue, 25 Sep 2012 21:10:40 -0700 Message-ID: <012401cd9b9c$e44f2d10$aced8730$@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: Ac2bWyxbZAoFfqW5RpS+yHqHep0I3Q== Content-Language: en-us Subject: [Emu] Review - draft-ietf-emu-eap-tunnel-method-00 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, 26 Sep 2012 04:12:06 -0000 Version 0 of the document is not ready for a last call as security considerations are missing. Other comments 1. I think in figure #1, there would be improved clarity if the line for Pear initiates connection to a service would have the following under the attacker line "-->|<--" to indicate that the attacker is intercepting the traffic at this point and forwarding it. 2. The last paragraph in section 1 need to be re-organized. a) It says there are several strategies, but I can only see two that are outlined here b) It is not clear where the second strategy starts. That is "is the technical solution part of the security solution". (yes I know that it is not) c) It is unclear if the cryptographic binding is unable to make the proof to the peer, or if this is just not done because the peer has traditionally not cared that it was so. 3. In section 2 I have a problem with the sentence "Channel bindings are used to tell the peer which application service is being connected to." I don't know that this is a good characterization of what is happening with channel bindings esp with the updated RFC in process. The issue I have is that not all of the information about the service is communicated to the peer, and the peer is told information about the service, but still might not know what service it is connected to. I think a better characterization might be "Channel bindings are used to provide the peer with information about the application service it is connecting to." 4. I would add an introductory sentence to paragraph #2 in section 2 to say this is the start of an example. 5. In section 3.2.2 - Item #1 seems to be a hardship to get implemented 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 configuration updated and transferred to the peer. 6. In section 3.2.4 - "then condition 3" need to tell me where condition 3 is - what section? 7. Missing paran " (see Section 3.3. insert" 8. In section 3.3 - can the intended intermediary be on the other side - that is between the NAS and the authenticator rather than the peer and the NAS? This is not clear from the text 9. In section 4.2 - there may be another piece of state tracking that should be added. It is not enough to know that mutual authentication has occurred, it might also be important to know who it has occurred with. Thus having performed mutual auth with a user is different than performing mutual auth with a machine and the operations that are allowed to take place may be different. 10. Section 5, 6 and 7 appear to be completely absent in the current draft. Jim From j@w1.fi Wed Sep 26 07:25:06 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 65A7921F86EF for ; Wed, 26 Sep 2012 07:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 Gs1-dRMUWcLj for ; Wed, 26 Sep 2012 07:25:06 -0700 (PDT) Received: from jmaline2.user.openhosting.com (kvm.w1.fi [128.177.28.162]) by ietfa.amsl.com (Postfix) with ESMTP id E1EE721F86DC for ; Wed, 26 Sep 2012 07:25:05 -0700 (PDT) Received: from jm (91-157-44-175.elisa-laajakaista.fi [91.157.44.175]) (authenticated bits=0) by jmaline2.user.openhosting.com (8.13.8/8.13.8) with ESMTP id q8QDqiMu022645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2012 09:52:46 -0400 Received: by jm (sSMTP sendmail emulation); Wed, 26 Sep 2012 17:24:52 +0300 Date: Wed, 26 Sep 2012 17:24:52 +0300 From: Jouni Malinen To: "Hao Zhou (hzhou)" Message-ID: <20120926142452.GA15764@w1.fi> References: <8739267zh3.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Simon Josefsson , "emu@ietf.org" Subject: Re: [Emu] Looking for reviewers 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, 26 Sep 2012 14:25:06 -0000 On Tue, Sep 25, 2012 at 06:55:48PM +0000, Hao Zhou (hzhou) wrote: > Thanks for the review. Good catch on both. We will fix both of them. What is the new Label for TLS Keying Material Exporter? "teap session key seed"? If so, is there any reason to not follow the recommended prefix for new uses as defined in RFC 5705 (see the relevant text below)? Labels here have the same definition as in TLS, i.e., an ASCII string with no terminating NULL. Label values beginning with "EXPERIMENTAL" MAY be used for private use without registration. All other label values MUST be registered via Specification Required as described by RFC 5226 [RFC5226]. Note that exporter labels have the potential to collide with existing PRF labels. In order to prevent this, labels SHOULD begin with "EXPORTER". This is not a MUST because there are existing uses that have labels which do not begin with this prefix. I would have expected to see something like "EXPORTER: teap session key seed" used as the Label for EAP-TEAP. Should the IANA Considerations section have somewhat more formal language to request registration of the new exporter label? TEAP makes use of the TLS Keying Material Exporters defined in [RFC5705]. The Label used in the derivation as defined in Section 5.1 is "teap seesion key seed". Maybe something like this: TEAP registers the label "EXPORTER: teap session key seed" in the TLS Exporter Label Registry. This label is used in derivation as defined in Section 5.1. -- Jouni Malinen PGP id EFC895FA From hzhou@cisco.com Thu Sep 27 07:24:54 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 594DC21F853B for ; Thu, 27 Sep 2012 07:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 D7456xVkfj2c for ; Thu, 27 Sep 2012 07:24:53 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BB3CC21F8437 for ; Thu, 27 Sep 2012 07:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1810; q=dns/txt; s=iport; t=1348755893; x=1349965493; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+VG6SFVHNxiVJn2Gl5686DTgY3CuQOMlMBGBu0oauqU=; b=DfbglzP6+tA16u80eeTz3ezst6EjcSpjeFnMIKLq8f9bwYBt/2yuQDy3 wSYaPpzQSk6kvzx9VxmaA2CbOMjlGrZIa3DHKb1Y4qjRUEkkJxcEKsZti jpsJEVGLtHOHV/wNCnJkvHX7ytKANn1KxMVkWbIKgYy5D65/gyDy3m5tP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACthZFCtJV2b/2dsb2JhbABFvgWBCIIgAQEBBBIBJz8SAQgOCh5CJQIEDgUih2OYPKAHixiGHQOSOIMxjkKBaYJnghc X-IronPort-AV: E=Sophos;i="4.80,496,1344211200"; d="scan'208";a="125739101" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 27 Sep 2012 14:24:53 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8REOrPc023155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Sep 2012 14:24:53 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Thu, 27 Sep 2012 09:24:52 -0500 From: "Hao Zhou (hzhou)" To: Jouni Malinen Thread-Topic: [Emu] Looking for reviewers Thread-Index: AQHNmy8Mk+bWhmFOD06VL7lBcSZhJJebWX7qgAAfpoCAAYmxAIABT0UA Date: Thu, 27 Sep 2012 14:24:51 +0000 Message-ID: In-Reply-To: <20120926142452.GA15764@w1.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [64.101.214.207] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19214.004 x-tm-as-result: No--43.552200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <16FCEFC1D28C0543BCDF0E099F57CB78@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Josefsson , "emu@ietf.org" Subject: Re: [Emu] Looking for reviewers 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, 27 Sep 2012 14:24:54 -0000 Jouni: Thanks for the suggestions. We will update that in the next draft. On 9/26/12 10:24 AM, "Jouni Malinen" wrote: >On Tue, Sep 25, 2012 at 06:55:48PM +0000, Hao Zhou (hzhou) wrote: >> Thanks for the review. Good catch on both. We will fix both of them. > >What is the new Label for TLS Keying Material Exporter? "teap >session key seed"? If so, is there any reason to not follow the >recommended prefix for new uses as defined in RFC 5705 (see the relevant >text below)? > > Labels here have the same definition as in TLS, i.e., an ASCII string > with no terminating NULL. Label values beginning with "EXPERIMENTAL" > MAY be used for private use without registration. All other label > values MUST be registered via Specification Required as described by > RFC 5226 [RFC5226]. Note that exporter labels have the potential to > collide with existing PRF labels. In order to prevent this, labels > SHOULD begin with "EXPORTER". This is not a MUST because there are > existing uses that have labels which do not begin with this prefix. > >I would have expected to see something like "EXPORTER: teap session key >seed" used as the Label for EAP-TEAP. > > >Should the IANA Considerations section have somewhat more formal >language to request registration of the new exporter label? > > TEAP makes use of the TLS Keying Material Exporters defined in > [RFC5705]. The Label used in the derivation as defined in > Section 5.1 is "teap seesion key seed". > > >Maybe something like this: > >TEAP registers the label "EXPORTER: teap session key seed" in the TLS >Exporter Label Registry. This label is used in derivation as defined in >Section 5.1. > >--=20 >Jouni Malinen PGP id EFC895FA From hzhou@cisco.com Fri Sep 28 09:30:17 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 C5D5C21F853D for ; Fri, 28 Sep 2012 09:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 xj+YVyNdffwR for ; Fri, 28 Sep 2012 09:30:17 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2604E21F851E for ; Fri, 28 Sep 2012 09:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3269; q=dns/txt; s=iport; t=1348849817; x=1350059417; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=C8a7G1Suop/WesSxDmvL6riZTh9MAWQW2WjvHNOaJIE=; b=c684zTAEZUbp5alAoNNcdW+ThVcs5ttcE7pY6jDstaukgxuJn+rPUbR5 3A+WbuxJc+Z160U7oRoJKFgmiva8bNLgN3wRBHN47kQl7YiPpp2TXEF2+ WvjwIXcwLSkkaHxax34+N9gO4RTdH1xMuWjnfKO/tQjw/5fRKN8Fhc4Q4 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAI7PZVCtJXG9/2dsb2JhbABFvg6BCIIiAQQBAQEPARQTNB0BCA4oNwslAQEEAQkJGweHYwuYEaAkBJE/A5VpjkKBaYJnghc X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208";a="126429760" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 28 Sep 2012 16:30:16 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8SGUGdG003015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Sep 2012 16:30:16 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Fri, 28 Sep 2012 11:30:16 -0500 From: "Hao Zhou (hzhou)" To: Jim Schaad , "emu@ietf.org" Thread-Topic: [Emu] Review - draft-ietf-emu-eap-tunnel-method-00 Thread-Index: Ac2bWyxbZAoFfqW5RpS+yHqHep0I3QCQ79yA Date: Fri, 28 Sep 2012 16:30:16 +0000 Message-ID: In-Reply-To: <012401cd9b9c$e44f2d10$aced8730$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.98.51.29] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19216.004 x-tm-as-result: No--37.480600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <406203CDAB22EC4C89C17E426BEFC5D6@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Emu] Review - draft-ietf-emu-eap-tunnel-method-00 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, 28 Sep 2012 16:30:17 -0000 Jim: Your comments were on draft-ietf-emu-crypto-bind-00.txt, not draft-ietf-emu-eap-tunnel-method? On 9/26/12 12:10 AM, "Jim Schaad" wrote: >Version 0 of the document is not ready for a last call as security >considerations are missing. > >Other comments > > >1. I think in figure #1, there would be improved clarity if the line for >Pear initiates connection to a service would have the following under the >attacker line "-->|<--" to indicate that the attacker is intercepting the >traffic at this point and forwarding it. > >2. The last paragraph in section 1 need to be re-organized. >a) It says there are several strategies, but I can only see two that are >outlined here >b) It is not clear where the second strategy starts. That is "is the >technical solution part of the security solution". (yes I know that it is >not) >c) It is unclear if the cryptographic binding is unable to make the proof >to >the peer, or if this is just not done because the peer has traditionally >not >cared that it was so. > >3. In section 2 I have a problem with the sentence "Channel bindings are >used to tell the peer which application service is being connected to." I >don't know that this is a good characterization of what is happening with >channel bindings esp with the updated RFC in process. The issue I have is >that not all of the information about the service is communicated to the >peer, and the peer is told information about the service, but still might >not know what service it is connected to. I think a better >characterization >might be "Channel bindings are used to provide the peer with information >about the application service it is connecting to." > >4. I would add an introductory sentence to paragraph #2 in section 2 to >say >this is the start of an example. > >5. In section 3.2.2 - Item #1 seems to be a hardship to get implemented >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 configuration >updated and transferred to the peer. > >6. In section 3.2.4 - "then condition 3" need to tell me where condition >3 >is - what section? > >7. Missing paran " (see Section 3.3. insert" > >8. In section 3.3 - can the intended intermediary be on the other side - >that is between the NAS and the authenticator rather than the peer and the >NAS? This is not clear from the text > >9. In section 4.2 - there may be another piece of state tracking that >should be added. It is not enough to know that mutual authentication has >occurred, it might also be important to know who it has occurred with. >Thus >having performed mutual auth with a user is different than performing >mutual >auth with a machine and the operations that are allowed to take place may >be >different. > >10. Section 5, 6 and 7 appear to be completely absent in the current >draft. > >Jim > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www.ietf.org/mailman/listinfo/emu From ietf@augustcellars.com Fri Sep 28 13:29: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 6C52F21F85FC for ; Fri, 28 Sep 2012 13:29:18 -0700 (PDT) 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 gbHibh4QFRkf for ; Fri, 28 Sep 2012 13:29:17 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id A883521F85F0 for ; Fri, 28 Sep 2012 13:29:17 -0700 (PDT) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 8C81838EF3 for ; Fri, 28 Sep 2012 13:29:17 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 28 Sep 2012 13:27:52 -0700 Message-ID: <005001cd9db7$bc8f8230$35ae8690$@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: Ac2dt554O+Xm0x5tRze3Cdvs6cX05g== Content-Language: en-us Subject: [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, 28 Sep 2012 20:29:18 -0000 As was pointed out to me, the subject message on the message had the wrong draft name (even if the version number was right). I am re-posting so that searches on the subject will find the correct document for comments. Jim > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Jim Schaad > Sent: Tuesday, September 25, 2012 9:11 PM > To: emu@ietf.org > Subject: [Emu] Review - draft-ietf-emu-eap-tunnel-method-00 > > Version 0 of the document is not ready for a last call as security > considerations are missing. > > Other comments > > > 1. I think in figure #1, there would be improved clarity if the line for Pear > initiates connection to a service would have the following under the attacker > line "-->|<--" to indicate that the attacker is intercepting the traffic at this > point and forwarding it. > > 2. The last paragraph in section 1 need to be re-organized. > a) It says there are several strategies, but I can only see two that are outlined > here > b) It is not clear where the second strategy starts. That is "is the technical > solution part of the security solution". (yes I know that it is > not) > c) It is unclear if the cryptographic binding is unable to make the proof to the > peer, or if this is just not done because the peer has traditionally not cared > that it was so. > > 3. In section 2 I have a problem with the sentence "Channel bindings are > used to tell the peer which application service is being connected to." I don't > know that this is a good characterization of what is happening with channel > bindings esp with the updated RFC in process. The issue I have is that not all > of the information about the service is communicated to the peer, and the > peer is told information about the service, but still might not know what > service it is connected to. I think a better characterization might be "Channel > bindings are used to provide the peer with information about the application > service it is connecting to." > > 4. I would add an introductory sentence to paragraph #2 in section 2 to say > this is the start of an example. > > 5. In section 3.2.2 - Item #1 seems to be a hardship to get implemented 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 configuration > updated and transferred to the peer. > > 6. In section 3.2.4 - "then condition 3" need to tell me where condition 3 is - > what section? > > 7. Missing paran " (see Section 3.3. insert" > > 8. In section 3.3 - can the intended intermediary be on the other side - that is > between the NAS and the authenticator rather than the peer and the NAS? > This is not clear from the text > > 9. In section 4.2 - there may be another piece of state tracking that should be > added. It is not enough to know that mutual authentication has occurred, it > might also be important to know who it has occurred with. Thus having > performed mutual auth with a user is different than performing mutual auth > with a machine and the operations that are allowed to take place may be > different. > > 10. Section 5, 6 and 7 appear to be completely absent in the current draft. > > Jim > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From ietf@augustcellars.com Fri Sep 28 18:19:41 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 08E9C21F859B for ; Fri, 28 Sep 2012 18:19:41 -0700 (PDT) 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 xBsYb4upzFgy for ; Fri, 28 Sep 2012 18:19:40 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0129D21F856C for ; Fri, 28 Sep 2012 18:19:39 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 0F8502C9BC for ; Fri, 28 Sep 2012 18:19:38 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 28 Sep 2012 18:18:14 -0700 Message-ID: <005d01cd9de0$4cd205c0$e6761140$@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: Ac2cRsi9sIvA7junTwesvqtA+uoKMg== Content-Language: en-us Subject: [Emu] Review of draft-ietf-emu-eap-tunnel-method-00 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, 29 Sep 2012 01:19:41 -0000 1. In section 3.2.3, it says that a new PAC can be requested after a full TLS handshake. Can one be requested following an abbreviated handshake? Or do you just re-use the existing PAC? 2. Section 3.3 s/descried/described/ 3. Section 3.4 - Is it possible to have multiple server ids after the authentication - one from the tunnel and others from the inner EAP methods. I realize that most EAP methods don't send a sender id, but some (IBAKE for example) currently do. Also, the client might have an idea of what the sender id is from configuration. If so, do these all need to get exported as server-id values? 4. In section 3.6.1 - It is not clear that an EAP-Failure packet is sent when 1) the server sends a fatal alert to the peer, 2) the peer requests a restart via a ClientHello and 3) the peer declines to permit the restart to occur. 5. In section 3.6.1 - Is the restart only an issue for fatal alerts, or is it a problem for all alerts? 6. In section 3.6.2 - Why SHOULD not MUST send clear text EAP-Failure? 7. In section 3.6 - do we need to discuss the question of errors in the outer EAP layer that is carrying the TLVs which contain the TLS content? This is a distinct location from the current list of where to handle errors. There is going to be a distinction (possibly) between errors that occur during phase 1 and errors during phase 2. Should the error return reflect if the error occurred inside or outside of the TLS tunnel? 8. In section 3.8 - I have the following questions a) In the text "The request MAY be issued", I don't understand the MAY at this point. Is it supposed to say that the request can be issued either before or after the authentication has finished, or is it saying that the peer has the option of issuing or not issuing the request, but must wait until the authentication level has been reached? b) If a peer issues a PAC request, but the server has not yet satisfied it's policy, does the server remember the PAC request and send back the response after the internal policy has been satisfied or should it send back an error saying that policy has not yet been satisfied along with additional TLVs to attempt and satisfy that policy? c) What should a peer do if it receives a PAC TLV with an unknown attribute? 9. In section 3.9 - there is leaking on the POP, but not on identity at this point. I believe that there needs to be a requirement that an EAP method needs to be run which will provide an identity proof on the client prior to a certificate being issued. You may or may not then want to add text that says that the subject name(s) in the certificate request need to be checked against the set of authenticated identities prior to the certificate being issued. 10. In section 3.10 - It is unclear to me if the Server Unauthenticated mode is because the server or the peer is unauthenticated at this point in time. The cipher suite would indicate that the server is not authenticated, however what about the case of the server providing an authenticated id to the peer, but the peer is unable to validate the identity of the server for some reason. This is also a Server Unauthenticated mode. 11. In section 4.1 - I would like to see a discussion that says that the following situation can never occur. The initial EAP message from the peer to the server (or the response) plus the Outer TLV data plus the EAP message headers exceeds the underlying packet size of the transport. In the event that it does, I am not sure how one finds the Outer TLV data start and where the fragmentation would occur to get the Outer TLV data between the peer and the server. 12. Section 4.2 - I understand what is happening with an EMPTY TEAP message being sent in response to a list of TLVs that are marked optional, however I question if the statement that is MUST be sent is correct. There are two reasons for the question: a. A server could send a RESULT TLV in response to a message from the client that contains no TLVs that are either mandatory or recognized. b. I am (very slightly) worried about the fact that the response is not authenticated by the tunnel in many manner. I would think that a NAK to any of the TLVs would be a better response if no other TLV messages are to be sent. The entity sending the TLV should know if it marked it as mandatory or not. The NAK is not the same as an Error TLV. 13. Section 4.2.2 - Should "Type" in the outdented list be "TLV Type"? s/filed/field/ 14. Section 4.2.2 - Can multiple Authority-ID TLVs be transmitted to a peer? 15. Section 4.2.3 - I assume that there should only be one Identity-Type TLV in a TEAP packet. Should a request for authentication be present in the packet as well? If multiple are allowed then information about how to treat this should be included. What should the peer respond with if it does have an identity of the type? This is not explicitly stated. 16. Section 4.2.4 - I don't understand the default in the event that an unknown value is sent in the status field. If there is an ERROR TLV in the message, should I not use that error code rather than change it? 17. Section 4.2.6 - Do we need a discussion about how to produce/deal with vender specific errors? Do you expect that vender specific TLVs will have an error mechanism built into them to return an error code? 18. Section 4.2.8 - Do we need to talk about the question of having some Vender TLVs be marked as mandatory and others not. Are we using the same TLV structure with the same rules for mandatoriness. If the mandatory bit is set, does that mean that I need to recognize the vendor-id or all combinations of vender-id/Vender-TLV type? 19. Section 4.2.9 - After reading this, sketching out some scenarios and so forth, I find that I do not like the text and result being pushed here at all. My problems start, in some respects, with the name of the TLV as it does not map to how I would like to see this TLV treated. I would propose the following set of changes: a) The name of the TLV be changed from Request-Action TLV to Provisional-Result TLV b) It needs to be made clear that the TLV can be sent from either the server to the peer or the peer to the server. It is my belief that presently it is only sent from the peer to the client and only in response to a successful Result TLV. c) The receiving entity MUST process the TLV. d) The processing for the TLV is as follows: i) The entity MAY choose to process (or start?) any of the TLVs that are included in the message. ii) If the entity chooses NOT to process any TLV in the list, the Provisional-Result TLV is treated as a Result TLV with the code "status" iii) If multiple Provisional-Result TLVs are in the body, the session can continue if ANY of TLV in any Provisional-Result TLV is processed. iv) If multiple Provisional-Result TLVs are in the body and no sub-TLV is processed, then the most fatal status should be used. If a status is found which is not understood by the entity, then it should be treated as a fatal TLV. The current text allows for the following: The server sends a Success to the peer The peer says please do this or go to fatal The server sends a clear success outside of the tunnel. I wonder if the capability needs to be added to say, please start this TLV. So that a server can say, If you don't start a Channel binding TLV, I will make this a failure return code, if you want to start the channel binding TLV then I am open to giving you a success return code. >> OK - so this is kind of there, but only one value can be placed there. One cannot say do either an EAP negotiation or process this TLV. 20. Section 4.2.12.4 - What does it mean to have an I-ID validation enforcement for PAC session renewal? Does it mean that the final message is not sent unless an appropriate ID is presented? Does it have to be an EAP authentication or is password based authentication sufficient? Should a PAC be invalidated on the server side (oops how do you do that) if it a PAC is presented and then the appropriate ID is not given? 21. In section 4.2.12.6 - Is this supposed to be at the top level or embedded in the PAC-TLV? 22. In section 4.2.16 - PKCS#7 has been superseded by CMS - the references should be to CMS and not to PCKS#7 23. In IANA - Need to add the Request-Action TLV to the list of status codes 24. In IANA - Should the Vender ID of the Vender-Specific TLV be kept in a registry? Jim > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Alan DeKok > Sent: Tuesday, September 25, 2012 8:04 AM > To: emu@ietf.org > Subject: [Emu] Looking for reviewers > > We'd like to get the final two documents into last call before the next > meeting. Therefore, we're looking for reviewers: > > https://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ > > https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ > > Please post reviews to the list. If all goes well, we can get updated > documents issued before the next meeting. > > Thanks to everyone for their help. > > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From ietf@augustcellars.com Sat Sep 29 13:49:12 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 B530B21F8645 for ; Sat, 29 Sep 2012 13:49:12 -0700 (PDT) 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 Dy+D6cnjZbez for ; Sat, 29 Sep 2012 13:49:12 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9E521F8624 for ; Sat, 29 Sep 2012 13:49:11 -0700 (PDT) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id B714F38F0C for ; Sat, 29 Sep 2012 13:49:11 -0700 (PDT) From: "Jim Schaad" To: Date: Sat, 29 Sep 2012 13:47:46 -0700 Message-ID: <008001cd9e83$ae8b6dd0$0ba24970$@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: Ac2eg6tSqiKv0jgeQPyrmZ8Se1AN6Q== Content-Language: en-us Subject: [Emu] IMSK derivation issue 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, 29 Sep 2012 20:49:12 -0000 I agree that the IMSK needs to take into account the existence of the EMSK, however the current text has a severe problem with the way that it is done. It assumes that if the EMSK is exportable on one side, then it will be exportable on the other side as well. I don't believe this is the case. In order for this to work, and to prevent the downgrade attack by a MITM, I believe that the following changes need to be made: 1. The first sender of the Crypto-Binding TLV needs to create it as follows: a) If the EMSK is not available, then it computes the Compound MAC as is currently documented b) If the EMSK is available, then it computes two Compound MAC values. The first is computed with the EMSK as is currently documented. The second is a Compound MAC that uses the MSK and the Buffer is modified by adding the string "EMSK" (or something similar). Both MACs are then send to the other side. 2. The second sender of the Crypto-Binding TLV then: a) If the EMSK is available and an EMSK Compound MAC was sent validates it and creates a response using the EMSK and sends it back b) If the EMSK is not available and an EMSK compound MAC was sent - it validates the MSK using the modified BUFFER string and sends back a MSK generated response c) If no EMSK Compound MAC was sent, it validates using the MSK - and if successful generates and returns an MSK generated response. If the EMSK compound MAC is removed in transit, then the MSK validated value will fail as the BUFFER string is not modified to recognize that an EMSK Compound MAC was sent. 3. The first send then validates the returned values by: a) If it sent an EMSK Compound value - attempt to validate using the EMSK value. If it fails then go to b else succeed b) Validate using the MSK value using the unmodified buffer. Both sides will then need to remember if the MSK or EMSK value was used for validation in this step, but that is no different than the fact that the MSK is currently being remembered. Jim From ietf@augustcellars.com Sun Sep 30 11:03:25 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 9E4C121F847F for ; Sun, 30 Sep 2012 11:03:25 -0700 (PDT) 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 3CV7g8JgmLR7 for ; Sun, 30 Sep 2012 11:03:25 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2E78621F847C for ; Sun, 30 Sep 2012 11:03:24 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 1420F38F0C; Sun, 30 Sep 2012 11:03:24 -0700 (PDT) From: "Jim Schaad" To: , Date: Sun, 30 Sep 2012 11:01:59 -0700 Message-ID: <009301cd9f35$b001e650$1005b2f0$@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: Ac2fNa8k+p3Xv8iySJGSGMwihVHFRQ== Content-Language: en-us Subject: [Emu] More comments for 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, 30 Sep 2012 18:03:25 -0000 1. Should the Message Length field be present if the TLS Data field is absent? 2. There is nothing to say which TLVs can and cannot occur in the Outer TLVs in any easily findable method. Either a table or the string outer in descriptions would be helpful. As an example, does the Authority-ID TLV in the outer TLV make sense? 3. I have gone through the fragmentation and did an implementation rather than just reading it. The questions that I have on it now are slightly different. Do TLVs need to be on a fragment boundary? Or do we just build the entire message, fragment it into convenient sizes regardless of the actual content of the message contents and sent the pieces across? If so then the text should probably be re-written to be clearer. Specifically, the message length is not useful for allocating the buffer on the first round trip of messages where one can have a TLV added in to the content.