From barryleiba@computer.org Tue Oct 1 12:02:28 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 3DE1511E8264; Tue, 1 Oct 2013 12:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 9umyWn92i2ig; Tue, 1 Oct 2013 12:02:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA0A11E8274; Tue, 1 Oct 2013 12:02:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131001190220.21382.44048.idtracker@ietfa.amsl.com> Date: Tue, 01 Oct 2013 12:02:20 -0700 Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org, emu-chairs@tools.ietf.org Subject: [Emu] Barry Leiba's No Objection on draft-ietf-emu-eap-tunnel-method-09: (with COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 19:02:28 -0000 Barry Leiba has entered the following ballot position for draft-ietf-emu-eap-tunnel-method-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Version -09 makes the negotiation process in Section 3.1 much clearer to me; thanks very much for addressing that. I note that the shepherd writeup included key information about reviews from outside the working group. Thanks for that; it's very useful. From kwiereng@cisco.com Fri Sep 27 09:07:57 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 9DA9F21F9EAF for ; Fri, 27 Sep 2013 09:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.489 X-Spam-Level: X-Spam-Status: No, score=-9.489 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, TVD_SPACE_RATIO=2.219] 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 D4D9x2wF+CBA for ; Fri, 27 Sep 2013 09:07:52 -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 6234D11E8101 for ; Fri, 27 Sep 2013 09:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1367; q=dns/txt; s=iport; t=1380298071; x=1381507671; h=from:to:subject:date:message-id:references:mime-version; bh=rtJU5KtLFMXamUIG+xleRDHUuuTj6EqzBcjUFNCqUcE=; b=nIWHnGgLOCtTw9wZ+ebD32kiKfl4bnwmivrXE5eOkdeRk2wxooT6S3xM UFAF2k+rMBHmy10AEqWdJ0ixIo1MYz5ovlGgwdepIMmbqa5GNlJ8ZnQWI Ly7x7yffY6LchZGk2j17lKrWffRXoN+doHsKMTdjaSAIsOPHGjeTNWsIi w=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwFALesRVKtJV2a/2dsb2JhbABbgwc4UsBLgRwWbQMEgiUBAQEDAX4LAgEZAwECCyQyGwIIAgQTCAaHcgYMuXuPICAegxmBAQOQJ4Ewh1eQSYMkgio X-IronPort-AV: E=Sophos;i="4.90,994,1371081600"; d="asc'?scan'208";a="265174089" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 27 Sep 2013 16:07:51 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8RG7o8I002859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Sep 2013 16:07:50 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.246]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 11:07:50 -0500 From: "Klaas Wierenga (kwiereng)" To: "emu@ietf.org" Thread-Topic: ID Tracker State Update Notice: Thread-Index: AQHOu41voe6PxgtES0WQHpUxJNx79A== Date: Fri, 27 Sep 2013 16:07:49 +0000 Message-ID: <7E1636E02F313F4BA69A428B314B77C709FE90B6@xmb-aln-x12.cisco.com> References: <20130927142514.11230.2759.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.61.105.62] Content-Type: multipart/signed; boundary="Apple-Mail=_4A4805F5-7677-4C54-A6F3-A052E0E5445E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 03 Oct 2013 09:09:32 -0700 Subject: [Emu] Fwd: ID Tracker State Update Notice: 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, 27 Sep 2013 16:07:57 -0000 --Apple-Mail=_4A4805F5-7677-4C54-A6F3-A052E0E5445E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI Begin forwarded message: > Resent-From: > From: IETF Secretariat > Subject: ID Tracker State Update Notice: = > Date: September 27, 2013 4:25:14 PM GMT+02:00 > Resent-To: , , = , > To: , = >=20 > IESG has approved the document and state has been changed to = Approved-announcement sent > ID Tracker URL: = http://datatracker.ietf.org/doc/draft-ietf-abfab-eapapplicability/ >=20 --Apple-Mail=_4A4805F5-7677-4C54-A6F3-A052E0E5445E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJFrUoACgkQH2Wy/p4XeFKAAACePjC+TUVsKDIrJCqSNZzFjzpq sYUAoMn2ATgnFmQ+w42NYDB62KBoAz3A =9pRO -----END PGP SIGNATURE----- --Apple-Mail=_4A4805F5-7677-4C54-A6F3-A052E0E5445E-- From mls.ietf@gmail.com Mon Sep 30 00:46:45 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 D9D8121F9B12; Mon, 30 Sep 2013 00:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 YkmJacICJ0xQ; Mon, 30 Sep 2013 00:46:44 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFD621F9BC1; Mon, 30 Sep 2013 00:46:36 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id b45so2519437eek.1 for ; Mon, 30 Sep 2013 00:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+PQPN1W16yVtXEtp1Obi3F3WBAYxnl5ippaosyJN/1U=; b=jL6J7LWGa07tCrCmysI3NBgQWjNmLAMUWXGsVLIM86tGL7mxs9PYs6t4TB2va/ivok QmZvovpiyy1BFpMeWlqgNDLc5J8GOO38Kte+vljllN6tGLrubxs+Ndko2icXr2rD7x98 YEjTUumVZU0Qzv7FQyoJ5yS8om+cjk5uNIzdNUpNJ7mcv5rSlr6O7nEc196sVoCtxxQ3 LqXO2X0888vtuPpJspLpynZ08/+Rm67uMvP5oFuGAipDdpOgFB+InqwYCizx9JedFlj4 UAfeyl5/JBi40fc6mgJLiL3dM/ZnUbCjwl1ZzJ/gGDE6E/sZ+ehYWCHz7UnjM13Ihfwg 6KCQ== X-Received: by 10.15.67.131 with SMTP id u3mr35153405eex.34.1380527194363; Mon, 30 Sep 2013 00:46:34 -0700 (PDT) Received: from ?IPv6:2001:1a80:2800:fa00:8d6d:4a0f:eac9:b19b? ([2001:1a80:2800:fa00:8d6d:4a0f:eac9:b19b]) by mx.google.com with ESMTPSA id v8sm48019544eeo.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Sep 2013 00:46:33 -0700 (PDT) Message-ID: <52492C4D.4020006@gmail.com> Date: Mon, 30 Sep 2013 09:46:21 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Sam Hartman References: <20130808192411.10939.54546.idtracker@ietfa.amsl.com> <52138FFE.8070307@neclab.eu> <5230675A.7020208@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Oct 2013 09:09:32 -0700 Cc: The IESG , "" , "" , "" , Martin Stiemerling Subject: Re: [Emu] Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS) 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, 30 Sep 2013 07:46:46 -0000 On 09/12/2013 10:39 PM, Sam Hartman wrote: >>>>>> "Martin" == Martin Stiemerling writes: > > Martin> Sam, > Martin> On 08/24/2013 03:41 PM, Sam Hartman wrote: > >>>>>>> "Martin" == Martin Stiemerling > >>>>>>> writes: > >> > Martin> Hi Sam, > Martin> On 08/14/2013 10:16 PM, Sam Hartman wrote: > >> >>>>>>> "Joseph" == Joseph Salowey (jsalowey) > >> >>>>>>> writes: > >> >> > Joseph> [Joe] Retransmission and timeout behavior for EAP is > Joseph> discussed in the EAP RFC 3748 Section 4.3. > >> >> > >> >> Echoing Joe's point, we over in abfab > >> (draft-ietf-abfab-gss-eap) >> would be really unhappy if EAP > >> method specs started discussing >> timeouts. > >> > Martin> It is not about the EAP timeouts for whole messages, but > Martin> timeouts for fragments are not defined in RFC 3748 and must > Martin> be defined somewhere, as well as, what happens if timeouts > Martin> are exceeded for fragments. > >> > >> If an inner method supports fragmentation, then each fragment is > >> a "whole EAP message," in your terminology quoting RFC 3748. > > Martin> So, for the unexperienced EAP people like me, TEAP is the > Martin> inner method? TEAP is running within EAP. > > *sigh* > I'm sorry, I used the wrong terminology. > Inner method doesn't come up here; that would be a case where say you > were running EAP-AKA inside TEAP. > > Rephrasing to apply to your situation. > If an EAP method supports fragmentation, that fragmentation is handled > by the method. That is both fragmented and un-fragmented messages > within the view of the method are "whole messages," as considered by > EAP. > > We see a similar situation with IP and ethernet. Ethernet (at least the > version I learned about back when ethernet was simple) doesn't support > fragmentation. Each IP datagram, whether it's a fragment or not, is a > whole ethernet frame. > > As it happens, ethernet doesn't provide end-to-end service, and for a > bunch of other reasons tdhat don't apply to EAP, you need to talk about > retransmission at the IP layer as well as to some extent at the ethernet > layer. > > However, with EAP, the EAP layer provides a reliable end-to-end service > and entirely takes on the retransmission task (unless EAP itself is > running over a lower layer that takes on retransmission and sets the EAP > retransmit timeout to infinite). > > A method can fragment, but unlike IP, the fragmentation mechanism is > entirely disjoint from retransmission. > > There are probably inefficiencies here because of that disconnect. > however, EAP is not trying to be an efficient transport. And handling > retransmission on the EAP side of the boundary and fragmentation on the > method side side of the abstraction boundary provides valuable benefits > for EAP. Like the state machine between the method and EAP can be > lock-step without the method ever triggering an event. That's quite > important for the way people have grown to build EAP software. Ok, I see. I will clear. Thanks, Martin > From stephen.farrell@cs.tcd.ie Fri Oct 4 07:14: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 3752921F9A90; Fri, 4 Oct 2013 07:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 nJ4VdHYIA9rf; Fri, 4 Oct 2013 07:14:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8D921F9D0A; Fri, 4 Oct 2013 07:07:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DD666BE62; Fri, 4 Oct 2013 15:07:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eceLdYUK674; Fri, 4 Oct 2013 15:07:20 +0100 (IST) Received: from [10.10.1.25] (unknown [201.221.11.150]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0D154BE5F; Fri, 4 Oct 2013 15:07:18 +0100 (IST) Message-ID: <524ECB8C.5020104@cs.tcd.ie> Date: Fri, 04 Oct 2013 15:07:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <20130814175831.1459.86153.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , The IESG , "" , "" Subject: Re: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) 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, 04 Oct 2013 14:14:58 -0000 Hi Joe, Sorry for the slow response and if I've missed anything... On 09/25/2013 07:21 AM, Joseph Salowey (jsalowey) wrote: > > On Aug 14, 2013, at 10:58 AM, Stephen Farrell > wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-emu-eap-tunnel-method-07: Discuss >> >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >> >> >> Please refer to >> http://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found >> here: >> http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ >> >> >> >> ---------------------------------------------------------------------- >> >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> >> These discuss points are more questions I'd really like >> answered than blocking points (depending on the answers I guess:-) >> but I expect should be easily resolved. >> >> (1) 3.4: when x.500 names or SubjectAltNames are "exported" is it >> clear how those are formatted? Maybe a pointer to where that's >> defined would be good in case implementers get it wrong. You might >> also want to warn here (or somewhere) about names that contain a >> null byte in case that attack is used e.g. with a TLS server cert >> subject name like "CN=www.paypal.com\0.badguy.com" Even though >> that's really a PKI failure, not detecting it here would be bad >> too. >> > > [Joe] We could add a note about the null, is there some text in an > existing document we could reuse? That one's a comment now. > >> (2) 5.2, at the end: this adds a dependency on the TLS-PRF. I >> don't suppose TLS1.3 will be a big enough change for that to be a >> problem, but what if it was? E.g. if someone convinced the TLS WG >> to use IKE instead? Do you really need the same PRF or could you >> pick one for TEAP and remove the dependency? Same question for the >> MAC in 5.3. >> > > [Joe] We chose to have the dependence so we would rely on the same > crypto-algorithms as TLS so our crypto agility would track with TLS. > We figured TLS would track advances in cryptography better than EMU. Well, two things - if TLS 1.3 makes changes then that could mean that this has to run over TLS 1.2 or earlier to get interop and that seems like a bad plan. And secondly, is there really a good API to see what PRF has been used by TLS for a given session in common TLS implementations? >> (3) 7.3: you have a MAY for this separation but also define what >> would become a cleartext password set of TLVs on the link between >> the two boxes here. Could you not at least REQUIRE protection (e.g. >> using IPsec) of that link if the basic password method will be >> used? >> > > [Joe] Sam's comments pretty much reflect the working group consensus > on this topic. I thought Sam was saying that it'd be good to add a recommendation but I didn't see new text on that, did I miss it, or am I confused? (Which is common:-) Cheers, S. > >> >> ---------------------------------------------------------------------- >> >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> >> - 3.2: You're allowing TLS compression. Is there the >> potential for something like a CRIME attack here? I guess not, >> given that there's no way to programatically get a peer or inner >> method server to send attacker-chosen data. Is that correct? (Just >> checking.) >> > > [Joe] In general no. The closest thing I can think of is NEA which > can use a method such as TEAP for transport, but I don't think this > would allow an attacker to launch a CRIME attack. > >> - 3.2.2: Since a PAC-lifetime is a wall-clock time then it would >> provide a way to correlate old and new sessions (i.e. act as a >> fingerprint) if its ever carried in clear. Can that happen? >> > > [Joe] The PAC-lifetime is carried in the PAC-Info which is always > send under the protection of the TLS tunnel. Only the PAC-Opaque is > sent outside the tunnel. > >> - 3.3.3, 1st para: what does "clear text" mean here? Do you mean >> within the TLS tunnel or not? I hope you do mean within the TLS >> tunnel, but I think you need to be clear(er) in any case. >> > > [Joe] Clear text means outside the TLS tunnel. EAP state machine > requires that the EAP-Success or EAP-Failure be sent independently of > the method. This is why TEAP has its own protected result indication > and why this section states that the Peer must not accept a cleartext > success or failure before the protected results are received. > >> - 3.8: this says mutual auth "results" if the peer trusts the >> server cert belongs to the server - that sounds wrong, isn't it? >> > > [Joe] I think this section is terminology challenged. It should > basically replace mutual server authentication with just server > authentication. > > "Several TEAP services including server unauthenticated > provisioning, PAC provisioning, certificate provisioning and channel > binding depend on the peer trusting the TEAP server. Peers MUST > authenticate the server before these peer services are used. > > TEAP peers MUST track whether server authentication has taken place. > Server authentication results if the peer trusts the provided server > certificate. Typically this involves both validating the certificate > to a trust anchor and confirming the entity named by the certificate > is the intended server. Server authentication also results when the > procedures of Section 3.3 are used to resume a session in which the > the peer and 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 is 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 server authenticated. TEAP peer implementations MUST > have a configuration where authentication fails if server > 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 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 participate in the authentication need to be > considered when evaluating whether to use peer services. " > > > >> - 3.8.1: I think you need an s/MAY/MUST/ here - you say the request >> "MAY be issued only ..." but I think you mean "MUST be issued >> only..." >> > > [Joe] Yes. How about: > > "The peer MUST successfully authenticated the EAP server and > validated the Crypto-Binding TLV as defined in Section 4.2.13 before > issuing the request" > > >> >> - 3.8.2: Just checking, and I may be wrong here. Say if I establish >> a TLS server-auth tunnel and then renegotiate to get TLS >> client-auth (with id privacy) as well, and then the Peer wants to >> get a new cert. This calls for the tls-unique for the initial >> server-auth TLS session to be used in the pkcs#10. Am I reading it >> right? Is that ok? I think it is, but just want to check since its >> pretty confusing;-) >> > > [Joe] This is meant to use the same mechanism as EST. It is > currently out of sync with the latest version. It should line up: > > In order to provide linking identity and proof-of-possession by > including information specific to the current authenticated TLS > session within the signed certification request, the peer generating > the request SHOULD obtain the tls-unique value from the TLS subsystem > as defined in Channel Bindings for TLS [RFC5929]. The TEAP peer > operations between obtaining the tls_unique value through generation > of the CSR that contains the current tls_unique value and the > subsequent verification of this value by the TEAP server are the > "phases of the application protocol during which application- layer > authentication occurs" that are protected by the synchronization > interoperability mechanism described in the Channel Bindings for TLS > [RFC5929] section 3.1 interoperability notes. When performing > renegotiation, TLS "secure_renegotiation" [RFC5746] MUST be used. > > The tls-unique value is base 64-encoded as specified in Section 4 of > [RFC4648] and the resulting string is placed in the certification > request challenge-password field ( [RFC2985], Section 5.4.1). The > challenge-password field is limited to 255 bytes (section 7.4.9 of > [RFC5246] indicates that no existing cipher suite would result in an > issue with this limitation). If tls-unique information is not > embedded within the certification request the challenge-password > field MUST be empty to indicate that the peer did not include the > optional channel-binding information (any value submitted is > verified by the server as tls-unique information). > > The server SHOULD verify the tls-unique information. This ensures > that the authenticated TEAP peer is in possession of the private key > used to sign the certification request. > > > >> - The secdir review [1] raised a couple of questions that I think >> would be good to answer. Did I miss that answer? >> > > [Joe] No, I missed the review. Response in progress. > >> [1] >> http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html >> >> >> _______________________________________________ Emu mailing list >> Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu > From jsalowey@cisco.com Fri Oct 4 09:58: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 013CC21F9CBF; Fri, 4 Oct 2013 09:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rO4kIiiC+bYj; Fri, 4 Oct 2013 09:58:35 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1878E21F99FB; Fri, 4 Oct 2013 09:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12867; q=dns/txt; s=iport; t=1380905915; x=1382115515; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ss//JpGGcyNWfOGIhWlihZa+sBtiL7gGAi5HhstEH7U=; b=kd4b0xNmKHmyxlxYgi3IzHXeX7DtDYmlaTXfJWAsFAN7rfsW3ms4YErC E0U1lbuq/i5ceg3MihnYeWwLqsRDt6xYZplml73PAUAw01tzjPg2KUUj9 B0P1CkKENtg+VfVKejb1ULN3nxQ9g+4+MMwCJxyBDzGtQt9qZVySSBFOB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAH7yTlKtJV2c/2dsb2JhbABQBgMBAggCgno4UsB+SoEaFnSCJQEBAQMBAQEBZAcLBQsCAQgYCg4LCycLJQIEDgUIAYd3Bgy8F44IBwMGgQYCMQIFDAUHgweBBAOJAYsjhQyQUIFmgT6BaAIHFwYc X-IronPort-AV: E=Sophos;i="4.90,1034,1371081600"; d="scan'208";a="265192723" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 04 Oct 2013 16:58:34 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r94GwYnE028828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Oct 2013 16:58:34 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.23]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 4 Oct 2013 11:58:33 -0500 From: "Joseph Salowey (jsalowey)" To: Stephen Farrell Thread-Topic: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) Thread-Index: AQHOwQsRNKCDjXOdx02v96mvaRGDcpnlF6UA Date: Fri, 4 Oct 2013 16:58:33 +0000 Message-ID: References: <20130814175831.1459.86153.idtracker@ietfa.amsl.com> <524ECB8C.5020104@cs.tcd.ie> In-Reply-To: <524ECB8C.5020104@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.127] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <73D9501AFD719148BF85475C3455308A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , The IESG , "" , "" Subject: Re: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) 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, 04 Oct 2013 16:58:40 -0000 On Oct 4, 2013, at 7:07 AM, Stephen Farrell wrote: >=20 > Hi Joe, >=20 > Sorry for the slow response and if I've missed anything... >=20 > On 09/25/2013 07:21 AM, Joseph Salowey (jsalowey) wrote: >>=20 >> On Aug 14, 2013, at 10:58 AM, Stephen Farrell >> wrote: >>=20 >>> Stephen Farrell has entered the following ballot position for=20 >>> draft-ietf-emu-eap-tunnel-method-07: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to >>> all email addresses included in the To and CC lines. (Feel free to >>> cut this introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to >>> http://www.ietf.org/iesg/statement/discuss-criteria.html for more >>> information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found >>> here:=20 >>> http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>>=20 >>>=20 > DISCUSS: >>> ---------------------------------------------------------------------- >>>=20 >>>=20 >>>=20 >>>=20 > These discuss points are more questions I'd really like >>> answered than blocking points (depending on the answers I guess:-) >>> but I expect should be easily resolved. >>>=20 >>> (1) 3.4: when x.500 names or SubjectAltNames are "exported" is it >>> clear how those are formatted? Maybe a pointer to where that's >>> defined would be good in case implementers get it wrong. You might >>> also want to warn here (or somewhere) about names that contain a >>> null byte in case that attack is used e.g. with a TLS server cert=20 >>> subject name like "CN=3Dwww.paypal.com\0.badguy.com" Even though >>> that's really a PKI failure, not detecting it here would be bad >>> too. >>>=20 >>=20 >> [Joe] We could add a note about the null, is there some text in an >> existing document we could reuse? >=20 > That one's a comment now. >=20 >>=20 >>> (2) 5.2, at the end: this adds a dependency on the TLS-PRF. I >>> don't suppose TLS1.3 will be a big enough change for that to be a >>> problem, but what if it was? E.g. if someone convinced the TLS WG >>> to use IKE instead? Do you really need the same PRF or could you >>> pick one for TEAP and remove the dependency? Same question for the >>> MAC in 5.3. >>>=20 >>=20 >> [Joe] We chose to have the dependence so we would rely on the same >> crypto-algorithms as TLS so our crypto agility would track with TLS. >> We figured TLS would track advances in cryptography better than EMU. >=20 > Well, two things - if TLS 1.3 makes changes then that could mean > that this has to run over TLS 1.2 or earlier to get interop and > that seems like a bad plan. > And secondly, is there really a good > API to see what PRF has been used by TLS for a given session in > common TLS implementations? >=20 [Joe] The TLS 1.2 the PRF is no longer fixed and it depends upon the cipher= suite. In most TLS implementations I'm aware of you can find the ciphersui= te. While this does not directly give you the PRF it does allow you to det= ermine what it is. THis does mean that a TEAP implementation would need to= have a mapping between ciphersuite and PRF. THis means that if a new cip= hersuite is defined TEAP implementations would need to make changes to supp= ort it. If the PRF is an existing PRF then adapting to the new Ciiphersuit= e is a simple addition to the mapping table which an implementation could a= ccommodate a configuration instead of a code change. If a new PRF is nee= ded then some code change is required to adapt the new PRF. The thinking h= ere is that the new PRF would have some benefit so you would want to use it= in TEAP as well as TLS. This does make TEAP tightly tied to a TLS impleme= ntation.=20 Is it your worry that changes in TLS 1.3 would make it not possible for a T= EAP implementation to to determine which PRF to use which would prevent int= erop? What sort of change are you anticipating in TLS 1.3 that would disrup= t this? =20 >>> (3) 7.3: you have a MAY for this separation but also define what >>> would become a cleartext password set of TLVs on the link between >>> the two boxes here. Could you not at least REQUIRE protection (e.g. >>> using IPsec) of that link if the basic password method will be >>> used? >>>=20 >>=20 >> [Joe] Sam's comments pretty much reflect the working group consensus >> on this topic. >=20 > I thought Sam was saying that it'd be good to add a recommendation > but I didn't see new text on that, did I miss it, or am I confused? > (Which is common:-) >=20 [Joe] I might be me that is confused. I was focused on the MTI security me= chanism, which I think we have consensus not to specify for this practice. = I think ti would be good to say that if you are going to do this you must = provide some sort of protection: If the request is to change the SHOULD to a MUST then I think that would be= OK (but I'd like to make sure the working group is OK with this): "The TEAP encrypting/decrypting gateway MUST, at a minimum, provide support for IPsec or similar protection in order to provide confidentiality for the portion of the conversation between the gateway and the EAP server. " > Cheers, > S. >=20 >>=20 >>>=20 >>> ---------------------------------------------------------------------- >>>=20 >>>=20 > COMMENT: >>> ---------------------------------------------------------------------- >>>=20 >>>=20 >>>=20 >>>=20 > - 3.2: You're allowing TLS compression. Is there the >>> potential for something like a CRIME attack here? I guess not, >>> given that there's no way to programatically get a peer or inner >>> method server to send attacker-chosen data. Is that correct? (Just >>> checking.) >>>=20 >>=20 >> [Joe] In general no. The closest thing I can think of is NEA which >> can use a method such as TEAP for transport, but I don't think this >> would allow an attacker to launch a CRIME attack. >>=20 >>> - 3.2.2: Since a PAC-lifetime is a wall-clock time then it would >>> provide a way to correlate old and new sessions (i.e. act as a >>> fingerprint) if its ever carried in clear. Can that happen? >>>=20 >>=20 >> [Joe] The PAC-lifetime is carried in the PAC-Info which is always >> send under the protection of the TLS tunnel. Only the PAC-Opaque is >> sent outside the tunnel. >>=20 >>> - 3.3.3, 1st para: what does "clear text" mean here? Do you mean >>> within the TLS tunnel or not? I hope you do mean within the TLS >>> tunnel, but I think you need to be clear(er) in any case. >>>=20 >>=20 >> [Joe] Clear text means outside the TLS tunnel. EAP state machine >> requires that the EAP-Success or EAP-Failure be sent independently of >> the method. This is why TEAP has its own protected result indication >> and why this section states that the Peer must not accept a cleartext >> success or failure before the protected results are received. >>=20 >>> - 3.8: this says mutual auth "results" if the peer trusts the >>> server cert belongs to the server - that sounds wrong, isn't it? >>>=20 >>=20 >> [Joe] I think this section is terminology challenged. It should >> basically replace mutual server authentication with just server >> authentication. >>=20 >> "Several TEAP services including server unauthenticated >> provisioning, PAC provisioning, certificate provisioning and channel >> binding depend on the peer trusting the TEAP server. Peers MUST=20 >> authenticate the server before these peer services are used. >>=20 >> TEAP peers MUST track whether server authentication has taken place.=20 >> Server authentication results if the peer trusts the provided server=20 >> certificate. Typically this involves both validating the certificate >> to a trust anchor and confirming the entity named by the certificate >> is the intended server. Server authentication also results when the >> procedures of Section 3.3 are used to resume a session in which the >> the peer and 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 is present (Section >> 4.2.13), then the session is mutually authenticated and peer services >> can be used. >>=20 >> TEAP implementations SHOULD NOT use peer services by default unless >> the session is server authenticated. TEAP peer implementations MUST >> have a configuration where authentication fails if server >> authentication cannot be achieved. >>=20 >> An additional complication arises when a tunnel method authenticates=20 >> multiple parties such as authenticating both the peer machine and >> the peer user to the EAP server. Depending on how 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 participate in the authentication need to be >> considered when evaluating whether to use peer services. " >>=20 >>=20 >>=20 >>> - 3.8.1: I think you need an s/MAY/MUST/ here - you say the request >>> "MAY be issued only ..." but I think you mean "MUST be issued >>> only..." >>>=20 >>=20 >> [Joe] Yes. How about: >>=20 >> "The peer MUST successfully authenticated the EAP server and >> validated the Crypto-Binding TLV as defined in Section 4.2.13 before >> issuing the request" >>=20 >>=20 >>>=20 >>> - 3.8.2: Just checking, and I may be wrong here. Say if I establish >>> a TLS server-auth tunnel and then renegotiate to get TLS >>> client-auth (with id privacy) as well, and then the Peer wants to >>> get a new cert. This calls for the tls-unique for the initial >>> server-auth TLS session to be used in the pkcs#10. Am I reading it >>> right? Is that ok? I think it is, but just want to check since its=20 >>> pretty confusing;-) >>>=20 >>=20 >> [Joe] This is meant to use the same mechanism as EST. It is >> currently out of sync with the latest version. It should line up: >>=20 >> In order to provide linking identity and proof-of-possession by=20 >> including information specific to the current authenticated TLS=20 >> session within the signed certification request, the peer generating=20 >> the request SHOULD obtain the tls-unique value from the TLS subsystem >> as defined in Channel Bindings for TLS [RFC5929]. The TEAP peer >> operations between obtaining the tls_unique value through generation >> of the CSR that contains the current tls_unique value and the >> subsequent verification of this value by the TEAP server are the >> "phases of the application protocol during which application- layer >> authentication occurs" that are protected by the synchronization=20 >> interoperability mechanism described in the Channel Bindings for TLS >> [RFC5929] section 3.1 interoperability notes. When performing >> renegotiation, TLS "secure_renegotiation" [RFC5746] MUST be used. >>=20 >> The tls-unique value is base 64-encoded as specified in Section 4 of >> [RFC4648] and the resulting string is placed in the certification=20 >> request challenge-password field ( [RFC2985], Section 5.4.1). The=20 >> challenge-password field is limited to 255 bytes (section 7.4.9 of >> [RFC5246] indicates that no existing cipher suite would result in an=20 >> issue with this limitation). If tls-unique information is not=20 >> embedded within the certification request the challenge-password=20 >> field MUST be empty to indicate that the peer did not include the=20 >> optional channel-binding information (any value submitted is >> verified by the server as tls-unique information). >>=20 >> The server SHOULD verify the tls-unique information. This ensures >> that the authenticated TEAP peer is in possession of the private key >> used to sign the certification request. >>=20 >>=20 >>=20 >>> - The secdir review [1] raised a couple of questions that I think >>> would be good to answer. Did I miss that answer? >>>=20 >>=20 >> [Joe] No, I missed the review. Response in progress. >>=20 >>> [1] >>> http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html >>>=20 >>>=20 >>> _______________________________________________ Emu mailing list=20 >>> Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu >>=20 From wwwrun@rfc-editor.org Wed Oct 9 09:20:25 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 EC70E11E81E1; Wed, 9 Oct 2013 09:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 7PgMnHR1lFnF; Wed, 9 Oct 2013 09:20:22 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BE78211E81EC; Wed, 9 Oct 2013 09:20:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2E29CB1E014; Wed, 9 Oct 2013 09:12:34 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131009161234.2E29CB1E014@rfc-editor.org> Date: Wed, 9 Oct 2013 09:12:34 -0700 (PDT) Cc: drafts-update-ref@iana.org, emu@ietf.org, rfc-editor@rfc-editor.org Subject: [Emu] RFC 7029 on Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding 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, 09 Oct 2013 16:20:25 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7029 Title: Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding Author: S. Hartman, M. Wasserman, D. Zhang Status: Informational Stream: IETF Date: October 2013 Mailbox: hartmans-ietf@mit.edu, mrw@painless-security.com, zhangdacheng@huawei.com Pages: 19 Characters: 45360 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-emu-crypto-bind-04.txt URL: http://www.rfc-editor.org/rfc/rfc7029.txt 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. Cryptographic binding is a facility described in RFC 3748 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 cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations. This document is a product of the EAP Method Update Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC