From jsalowey@cisco.com Tue Jan 7 21:28:18 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B82F1AE0B7 for ; Tue, 7 Jan 2014 21:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQraJcSDYi8D for ; Tue, 7 Jan 2014 21:28:14 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2F81ADFC9 for ; Tue, 7 Jan 2014 21:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18501; q=dns/txt; s=iport; t=1389158885; x=1390368485; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Gl9vorGZdrIqN8l4Vs1HwHAmX3WHuFFNoK5Ar+DPENQ=; b=csNdhdz/4j6ryWw6qgbgnn9uQcZ+VfRMobZ6DEs/JUtJLq+y+EbJsTyv RQ1EunjT60s96pnuvTEHKRSRPFgHEBNcJMlPMHyYbNbv86Ko0uwb35ZSf 6M0Hgoioj+MRge9/bn021nPX/AmHfBlMLYHjYDi/d8mwO6WLjUxvBb+O4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FACThzFKtJV2a/2dsb2JhbABQBgMBAggCgn44VbkmT4EPFnSCJQEBAQMBAQEBNy0HCwwEAgEIEQQBAQEYBgUEBycLFAkIAgQOBQkLh2gIDcQ+F44iBwMGAgEcMwIFBgYFB4MMgRMElDODZIEwkGWBb4E+gWgCHgYc X-IronPort-AV: E=Sophos;i="4.95,622,1384300800"; d="scan'208";a="295942804" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 08 Jan 2014 05:28:03 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s085S2xu007632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jan 2014 05:28:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Tue, 7 Jan 2014 23:28:02 -0600 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: AQHOwQsRNKCDjXOdx02v96mvaRGDcpnlF6UAgDX6AwCAAAZngIABPPWAgA68XICAUDXqgA== Date: Wed, 8 Jan 2014 05:28:01 +0000 Message-ID: References: <20130814175831.1459.86153.idtracker@ietfa.amsl.com> <524ECB8C.5020104@cs.tcd.ie> <527C2D0C.3000803@cs.tcd.ie> <5E413854-4EF4-446E-B177-686337F95744@cisco.com> <084301cedcb9$439ebca0$cadc35e0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.158] Content-Type: text/plain; charset="us-ascii" Content-ID: <9BF95C59C7AAB64085BA81AB9EAD13E7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-emu-eap-tunnel-method@tools.ietf.org" , "emu@ietf.org" , "emu-chairs@tools.ietf.org" 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.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 05:28:18 -0000 I would like to move forward here. I think the way we have the TEAP PRF defined does create a linkage between = TLS and TEAP. The TLS implementations I looked at all provide3 a way to ge= t the TLS version and cipher suite in use for a TLS session, so this approa= ch should be implementable across a wide variety of TLS libraries. We cou= ld define a PRF specific to TEAP and remove this linkage, but then it is ei= ther fixed and bound to be found insufficient by some community or we have = to negotiate it, in which case it seems that it would be better to leverage= what TLS uses. =20 Using the same PRF as TLS uses was decided through working group consensus = so I think we should keep it that way. If there still is a concern, then w= hat is the main objection to using the PRF used by the TLS session. =20 Thanks, Joe On Nov 17, 2013, at 8:34 PM, Joseph Salowey (jsalowey) = wrote: >=20 > On Nov 8, 2013, at 11:32 AM, Jim Schaad wrote: >=20 >> Looking for a piece of information. >>=20 >> Are there cases in TLS before 1.3 where the PRF and the MAC are not infe= rred >> from the cipher suite that was negotiated? >>=20 >=20 > [Joe] You would need to know both the cipher suite and the TLS version nu= mber negotiated to determine what the PRF and MAC in use are. Before TLS 1.= 2 the PRF was fixed. TLS 1.2 allowed the PRF to depend upon the ciphersuit= e. TEAP requires 1.2. so the cipher suite information is enough. All = the cipher suites in RFC 5246 use a PRF based on SHA-256. =20 >=20 >> I think it would be surprising if the cipher suite was not obtainable. = The >> question would be if these are ever independent of the suite there could= be >> a problem.=20 >>=20 >=20 > [Joe] I've looked at many of the libraries and they all provide a mechan= ism to get the negotiated cipher suite. I would have to go back to check= to see if the provided version information. I believe that many of them d= o. =20 >=20 >=20 >> Jim >>=20 >>=20 >>> -----Original Message----- >>> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of >>> Joseph Salowey (jsalowey) >>> Sent: Thursday, November 07, 2013 4:38 PM >>> To: emu@ietf.org >>> Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org; emu- >>> chairs@tools.ietf.org; Stephen Farrell >>> Subject: Re: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunn= el- >>> method-07: (with DISCUSS and COMMENT) >>>=20 >>> I'd like to hear from the working group on this. >>>=20 >>> I think Stephen is raising a fair point that trying to use the TLS PRF = in >> this way >>> creates a very tight binding between a TLS implementation and a TEAP >>> implementation that may make implementations difficult depending upon t= he >>> interfaces provided by a TLS library. I think its very possible that >> some >>> libraries would not provide this information. If you think reusing th= e >> TLS PRF >>> is a good idea then please state why. If you think we should define a >> PRF >>> please indicate what approach you think we should take. >>>=20 >>> Thanks, >>>=20 >>> Joe >>>=20 >>>=20 >>> On Nov 7, 2013, at 4:15 PM, Stephen Farrell >>> wrote: >>>=20 >>>>=20 >>>> Hi Joe, >>>>=20 >>>> On 10/04/2013 05:58 PM, Joseph Salowey (jsalowey) wrote: >>>>>=20 >>>>=20 >>>> Apologies for the glacial response. >>>>=20 >>>> Your suggestion for point 3 looks fine. Point 1 is already a comment. >>>>=20 >>>> But point 2 needs a bit more discussion. >>>>=20 >>>> The concern is that you're doing a layering violation and we know that >>>> the layer below (TLS) is changing, possibly in a way that'd impact on >>>> this. Why not just pick a KDF? >>>>=20 >>>> S. >>>>=20 >>>>> On Oct 4, 2013, at 7:07 AM, Stephen Farrell >>>>> >>>>> wrote: >>>>>=20 >>>>>>=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 >>>>>>>> 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: >>>>>>>> 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 >>>>>>>> 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 >>> ciphersuite. In most TLS implementations I'm aware of you can find the >>> ciphersuite. While this does not directly give you the PRF it does all= ow >> you to >>> determine 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 n= ew >>> ciphersuite is defined TEAP implementations would need to make changes = to >>> support it. If the PRF is an existing PRF then adapting to the new >> Ciiphersuite >>> is a simple addition to the mapping table which an implementation could >>> accommodate a configuration instead of a code change. If a new PRF i= s >>> needed then some code change is required to adapt the new PRF. The >>> thinking here 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 >>> implementation. >>>>>=20 >>>>> Is it your worry that changes in TLS 1.3 would make it not possible f= or >> a >>> TEAP implementation to to determine which PRF to use which would preven= t >>> interop? What sort of change are you anticipating in TLS 1.3 that would >>> disrupt this? >>>>>=20 >>>>>=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 >>>>>=20 >>>>> [Joe] I might be me that is confused. I was focused on the MTI >> security >>> mechanism, 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: >>>>>=20 >>>>> 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): >>>>>=20 >>>>> "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. " >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> 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 authenticate the server before these peer services are used. >>>>>>>=20 >>>>>>> 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. >>>>>>>=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 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 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 >>>>>>> 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. >>>>>>>=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 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). >>>>>>>=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 >>>>>>>> Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu >>>>>>>=20 >>>>>=20 >>>=20 >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www.ietf.org/mailman/listinfo/emu >>=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From jsalowey@cisco.com Tue Jan 7 21:59:40 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39381AE127 for ; Tue, 7 Jan 2014 21:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8H3n8yhWIT0M for ; Tue, 7 Jan 2014 21:59:39 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6CE1AE01A for ; Tue, 7 Jan 2014 21:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2120; q=dns/txt; s=iport; t=1389160770; x=1390370370; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=IlVPY//iHvbBnf4AmLOsc7e0hS6qxSpBF/Uc50TWpIw=; b=i+2lfUGNS+ACBClY/J/njLN44WIsVuNSGo//jQ0lscCxprozVXZrdj1b 6H6zFgyaaWrTeFGEsNPgsusjzafNJ8t2v001M+l+EEKErlpfvqg/L/bp3 3wQpzVm1YU0o2mjzc/JgLEihj4YNjF55Yt4GT09JNCdC37JzUACSOuscb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAN3ozFKtJV2d/2dsb2JhbABZgwuBDbsFFnSCLDpRAT5CJwSIF5pSqWwXkjCBEwSYF5IVgy2BaiQc X-IronPort-AV: E=Sophos;i="4.95,622,1384300800"; d="scan'208";a="11288235" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 08 Jan 2014 05:59:29 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s085xUDx021551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 8 Jan 2014 05:59:30 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Tue, 7 Jan 2014 23:59:30 -0600 From: "Joseph Salowey (jsalowey)" To: "emu@ietf.org" Thread-Topic: Crypto Binding in TEAP Thread-Index: AQHPDDbLYRrW9Q2mmEuj+nyCLSqyJw== Date: Wed, 8 Jan 2014 05:59:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.158] Content-Type: text/plain; charset="us-ascii" Content-ID: <2708FA7E5C16A940B28C2B4D11527EB6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Emu] Crypto Binding in TEAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 05:59:41 -0000 In some discussions recently its become clear to me that the properties of = crypto binding in TEAP may not be clear to everyone. TEAP crypto bindings= main prevent a MiTM attack when an inner method is allowed both inside and= outside the tunnel (the Asokan attack). The crypto binding does not nece= ssary protect from a MitM attack the inner method is run inside an authenti= cated tunnel and the TLS server certificate is not checked by the client. = THis is because the crypto binding relies upon the TLS master secret. With= some commonly used TLS ciphers (RSA key transport) the master secret is en= tirely in control of the client an attacker can insert himself in the middl= e and force both sides to negotiate the same TLS master secret that he know= s. TLS ciphersuites that are based on ephemeral Diffie-Hellman (RSA-DHE) = prevent a MitM from forcing the TLS secret on client and server to be the s= ame as long as the DH parameters are validated correctly.=20 I think we should clarify this in the security considerations section: Add to section 7.4.3: "TEAP crypto binding does not guarantee man-in-the-middle protection if the= client does not validate the server's certificate. If the TLS ciphersui= te derives the master secret solely from the contribution of secrets from = one side of the conversation (such as RSA key transport based ciphersuites)= then an attacker can insert themselves in the conversation if the server c= ertificate is not verified even if a strong inner method is executed within= the tunnel. If the TLS ciphersuite derives the master secret from the co= ntribution of secrets from both sides of the conversation (such as in Diffi= e-Hellman based cipher suites) then crypto binding can detect an attacker i= n the conversation if a strong inner method is used. "=20 Currently we have TLS_RSA_WITH_AES_128_CBC_SHA and TLS_DHE_RSA_WITH_AES_12= 8_CBC_SHA as MUST implement. Perhaps we should just make TLS_DHE_RSA_WITH_= AES_128_CBC_SHA a MUST implement and leave the RSA suite as SHOULD or MAY. = =20 Thanks, Joe From stephen.farrell@cs.tcd.ie Wed Jan 8 02:48:35 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599B81AE235 for ; Wed, 8 Jan 2014 02:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaPJah8h4GtU for ; Wed, 8 Jan 2014 02:48:30 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B43B01AE223 for ; Wed, 8 Jan 2014 02:48:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 995B3BE49; Wed, 8 Jan 2014 10:48:19 +0000 (GMT) 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 4jhy0nTmifdB; Wed, 8 Jan 2014 10:48:19 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 67E46BE3F; Wed, 8 Jan 2014 10:48:19 +0000 (GMT) Message-ID: <52CD2CF3.2050508@cs.tcd.ie> Date: Wed, 08 Jan 2014 10:48:19 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <20130814175831.1459.86153.idtracker@ietfa.amsl.com> <524ECB8C.5020104@cs.tcd.ie> <527C2D0C.3000803@cs.tcd.ie> <5E413854-4EF4-446E-B177-686337F95744@cisco.com> <084301cedcb9$439ebca0$cadc35e0$@augustcellars.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-emu-eap-tunnel-method@tools.ietf.org" , "emu@ietf.org" , "emu-chairs@tools.ietf.org" 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.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 10:48:35 -0000 Hiya, On 01/08/2014 05:28 AM, Joseph Salowey (jsalowey) wrote: > I would like to move forward here. Yep. > I think the way we have the TEAP PRF defined does create a linkage > between TLS and TEAP. The TLS implementations I looked at all > provide3 a way to get the TLS version and cipher suite in use for a > TLS session, so this approach should be implementable across a wide > variety of TLS libraries. We could define a PRF specific to TEAP > and remove this linkage, but then it is either fixed and bound to be > found insufficient by some community or we have to negotiate it, in > which case it seems that it would be better to leverage what TLS > uses. > > Using the same PRF as TLS uses was decided through working group > consensus so I think we should keep it that way. If there still is a > concern, then what is the main objection to using the PRF used by the > TLS session. Ok, how's about just adding a note somewhere for implementers to say that you need a TLS library that'll do as you describe above and then we consider this as done? I'd say calling out the dependency would be good. I'm assuming that you Joe can raise an alarm if the TLS1.3 work heads towards doing something that'd mean breaking TEAP/TLS1.3, and I'm fine with that. Cheers, S. > > Thanks, > > Joe > > > > On Nov 17, 2013, at 8:34 PM, Joseph Salowey (jsalowey) > wrote: > >> >> On Nov 8, 2013, at 11:32 AM, Jim Schaad >> wrote: >> >>> Looking for a piece of information. >>> >>> Are there cases in TLS before 1.3 where the PRF and the MAC are >>> not inferred from the cipher suite that was negotiated? >>> >> >> [Joe] You would need to know both the cipher suite and the TLS >> version number negotiated to determine what the PRF and MAC in use >> are. Before TLS 1.2 the PRF was fixed. TLS 1.2 allowed the PRF to >> depend upon the ciphersuite. TEAP requires 1.2. so the cipher >> suite information is enough. All the cipher suites in RFC 5246 >> use a PRF based on SHA-256. >> >>> I think it would be surprising if the cipher suite was not >>> obtainable. The question would be if these are ever independent >>> of the suite there could be a problem. >>> >> >> [Joe] I've looked at many of the libraries and they all provide a >> mechanism to get the negotiated cipher suite. I would have to go >> back to check to see if the provided version information. I >> believe that many of them do. >> >> >>> Jim >>> >>> >>>> -----Original Message----- From: emu-bounces@ietf.org >>>> [mailto:emu-bounces@ietf.org] On Behalf Of Joseph Salowey >>>> (jsalowey) Sent: Thursday, November 07, 2013 4:38 PM To: >>>> emu@ietf.org Cc: >>>> draft-ietf-emu-eap-tunnel-method@tools.ietf.org; emu- >>>> chairs@tools.ietf.org; Stephen Farrell Subject: Re: [Emu] >>>> Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel- >>>> method-07: (with DISCUSS and COMMENT) >>>> >>>> I'd like to hear from the working group on this. >>>> >>>> I think Stephen is raising a fair point that trying to use the >>>> TLS PRF in >>> this way >>>> creates a very tight binding between a TLS implementation and a >>>> TEAP implementation that may make implementations difficult >>>> depending upon the interfaces provided by a TLS library. I >>>> think its very possible that >>> some >>>> libraries would not provide this information. If you think >>>> reusing the >>> TLS PRF >>>> is a good idea then please state why. If you think we should >>>> define a >>> PRF >>>> please indicate what approach you think we should take. >>>> >>>> Thanks, >>>> >>>> Joe >>>> >>>> >>>> On Nov 7, 2013, at 4:15 PM, Stephen Farrell >>>> wrote: >>>> >>>>> >>>>> Hi Joe, >>>>> >>>>> On 10/04/2013 05:58 PM, Joseph Salowey (jsalowey) wrote: >>>>>> >>>>> >>>>> Apologies for the glacial response. >>>>> >>>>> Your suggestion for point 3 looks fine. Point 1 is already a >>>>> comment. >>>>> >>>>> But point 2 needs a bit more discussion. >>>>> >>>>> The concern is that you're doing a layering violation and we >>>>> know that the layer below (TLS) is changing, possibly in a >>>>> way that'd impact on this. Why not just pick a KDF? >>>>> >>>>> S. >>>>> >>>>>> On Oct 4, 2013, at 7:07 AM, Stephen Farrell >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> 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? >>>>>>> >>>>>> [Joe] The TLS 1.2 the PRF is no longer fixed and it depends >>>>>> upon the >>>> ciphersuite. In most TLS implementations I'm aware of you can >>>> find the ciphersuite. While this does not directly give you >>>> the PRF it does allow >>> you to >>>> determine 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 ciphersuite is defined TEAP implementations would >>>> need to make changes to support it. If the PRF is an existing >>>> PRF then adapting to the new >>> Ciiphersuite >>>> is a simple addition to the mapping table which an >>>> implementation could accommodate a configuration instead of a >>>> code change. If a new PRF is needed then some code change is >>>> required to adapt the new PRF. The thinking here 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 >>>> implementation. >>>>>> >>>>>> Is it your worry that changes in TLS 1.3 would make it not >>>>>> possible for >>> a >>>> TEAP implementation to to determine which PRF to use which >>>> would prevent interop? What sort of change are you anticipating >>>> in TLS 1.3 that would disrupt this? >>>>>> >>>>>> >>>>>>>>> (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:-) >>>>>>> >>>>>> >>>>>> [Joe] I might be me that is confused. I was focused on the >>>>>> MTI >>> security >>>> mechanism, 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. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> ---- >>>>>>>>> >>>>>>>>> >>>>>>> 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 >>>>>>>> >>>>>> >>>> >>>> _______________________________________________ Emu mailing >>>> list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu >>> >> >> _______________________________________________ Emu mailing list >> Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu > From internet-drafts@ietf.org Wed Jan 8 17:00:21 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660EC1ADF46; Wed, 8 Jan 2014 17:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UE9-DDhJbC6S; Wed, 8 Jan 2014 17:00:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 141981AD8F4; Wed, 8 Jan 2014 17:00:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140109010019.23121.36233.idtracker@ietfa.amsl.com> Date: Wed, 08 Jan 2014 17:00:19 -0800 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-eap-tunnel-method-10.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 01:00:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of the IE= TF. Title : Tunnel EAP Method (TEAP) Version 1 Authors : Hao Zhou Nancy Cam-Winget Joseph Salowey Stephen Hanna Filename : draft-ietf-emu-eap-tunnel-method-10.txt Pages : 107 Date : 2014-01-08 Abstract: This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-eap-tunnel-method-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Jan 8 17:00:22 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99EF21ADF46 for ; Wed, 8 Jan 2014 17:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbZgG5rfOa30; Wed, 8 Jan 2014 17:00:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 449C01ADF26; Wed, 8 Jan 2014 17:00:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: emu-chairs@tools.ietf.org, draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140109010020.23121.86609.idtracker@ietfa.amsl.com> Date: Wed, 08 Jan 2014 17:00:20 -0800 Subject: [Emu] New Version Notification - draft-ietf-emu-eap-tunnel-method-10.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 01:00:22 -0000 A new version (-10) has been submitted for draft-ietf-emu-eap-tunnel-method: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-tunnel-method-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-eap-tunnel-method-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From jsalowey@cisco.com Wed Jan 8 17:09:04 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774851ADF46 for ; Wed, 8 Jan 2014 17:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_bkmpNdxVEo for ; Wed, 8 Jan 2014 17:09:00 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id E477D1ADF0E for ; Wed, 8 Jan 2014 17:08:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22673; q=dns/txt; s=iport; t=1389229731; x=1390439331; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cttxEYMi7rsdQ2IE4+rEJj71PZhJCpmk5DNcz5NA9wA=; b=jweXp6S51dXMlrxj1uVBCq3Em/7zKJWimDqYQXZndqu+n6yhnn386CBk B3abCKehXXAQ1mI849XNxioCp7t0kU5PuCxrUPHzhzvo2xpl9oapWNAmh fToPwDspmncnqIVpKgK3QVJ4drU0se/Zbd8R9vACnBAChEO+FEWbCQFNg c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAKj1zVKtJXHB/2dsb2JhbABQBgMBAggCgn44VrhxT4EOFnSCJQEBAQMBAQEBF00HCwwEAgEIEQQBAQEYCwQHJwsUCQgCBAENBQkLB4dhCA3EQheOIwcDBgIBHBEiAgUGBgUHgwyBEwSJC4sog2SBMJBlgW+BPoFoAh4GHA X-IronPort-AV: E=Sophos;i="4.95,627,1384300800"; d="scan'208";a="11525240" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-8.cisco.com with ESMTP; 09 Jan 2014 01:08:49 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0918n2U016808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jan 2014 01:08:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Wed, 8 Jan 2014 19:08:49 -0600 From: "Joseph Salowey (jsalowey)" To: Stephen Farrell , "emu@ietf.org" Thread-Topic: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) Thread-Index: AQHOwQsRNKCDjXOdx02v96mvaRGDcpnlF6UAgDX6AwCAAAZngIABPPWAgA68XICAUDXqgIAAWX2AgADwawA= Date: Thu, 9 Jan 2014 01:08:49 +0000 Message-ID: References: <20130814175831.1459.86153.idtracker@ietfa.amsl.com> <524ECB8C.5020104@cs.tcd.ie> <527C2D0C.3000803@cs.tcd.ie> <5E413854-4EF4-446E-B177-686337F95744@cisco.com> <084301cedcb9$439ebca0$cadc35e0$@augustcellars.com> <52CD2CF3.2050508@cs.tcd.ie> In-Reply-To: <52CD2CF3.2050508@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.158] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6316C31C303E5B43B6D3FE89C3B8F5E6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-emu-eap-tunnel-method@tools.ietf.org" , "emu-chairs@tools.ietf.org" 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.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 01:09:04 -0000 Hi Folks, I uploaded a -10 revision to address the comments: http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-10 In section 5 I added some text to address the Discuss on TLS PRF: "For key derivation and crypto-binding, TEAP uses the PRF and MAC=09 algorithms negotiated in the underlying TLS session. Since these=09 algorithms depend on the TLS version and cipher suite, TEAP=09 implementations need a mechanism to determine the version and cipher=09 suite in use for a particular session. The implementation can then=09 use this information to determine which PRF and MAC algorithm to use." In Section 7.3 I modified the text to require protection if the tunnel does= not reach to the authentication server: "... In these cases, using a proxy solution without end-to-end protection of TEAP MAY be used. The TEAP encrypting/decrypting gateway MUST, at a minimum, provide support for IPsec, TLS or similar protection in order to provide confidentiality for the portion of the conversation between the gateway and the EAP server. ..." In section 7.4.3 I added some additional clarifications on MITM protection: "TEAP crypto binding does not guarantee man-in-the-middle protection if the client does not validate the server's certificate. If the TLS cipher suite derives the master secret solely from the contribution of secret data from one side of the conversation (such as RSA key transport based ciphersuites) then an attacker can insert themselves in the conversation if the server certificate is not verified even if a strong inner method is executed within the tunnel. If the TLS ciphersuite derives the master secret from the contribution of secrets from both sides of the conversation (such as in Diffie- Hellman based cipher suites) then crypto binding can detect an attacker in the conversation if a strong inner method is used." Let me know if you see any additional or unresolved issues. Thanks, Joe On Jan 8, 2014, at 2:48 AM, Stephen Farrell wro= te: >=20 > Hiya, >=20 > On 01/08/2014 05:28 AM, Joseph Salowey (jsalowey) wrote: >> I would like to move forward here. >=20 > Yep. >=20 >> I think the way we have the TEAP PRF defined does create a linkage >> between TLS and TEAP. The TLS implementations I looked at all >> provide3 a way to get the TLS version and cipher suite in use for a >> TLS session, so this approach should be implementable across a wide >> variety of TLS libraries. We could define a PRF specific to TEAP >> and remove this linkage, but then it is either fixed and bound to be >> found insufficient by some community or we have to negotiate it, in >> which case it seems that it would be better to leverage what TLS >> uses. >>=20 >> Using the same PRF as TLS uses was decided through working group >> consensus so I think we should keep it that way. If there still is a >> concern, then what is the main objection to using the PRF used by the >> TLS session. >=20 > Ok, how's about just adding a note somewhere for implementers > to say that you need a TLS library that'll do as > you describe above and then we consider this as done? > I'd say calling out the dependency would be good. >=20 > I'm assuming that you Joe can raise an alarm if the TLS1.3 > work heads towards doing something that'd mean breaking > TEAP/TLS1.3, and I'm fine with that. >=20 > Cheers, > S. >=20 >=20 >>=20 >> Thanks, >>=20 >> Joe >>=20 >>=20 >>=20 >> On Nov 17, 2013, at 8:34 PM, Joseph Salowey (jsalowey) >> wrote: >>=20 >>>=20 >>> On Nov 8, 2013, at 11:32 AM, Jim Schaad >>> wrote: >>>=20 >>>> Looking for a piece of information. >>>>=20 >>>> Are there cases in TLS before 1.3 where the PRF and the MAC are >>>> not inferred from the cipher suite that was negotiated? >>>>=20 >>>=20 >>> [Joe] You would need to know both the cipher suite and the TLS >>> version number negotiated to determine what the PRF and MAC in use >>> are. Before TLS 1.2 the PRF was fixed. TLS 1.2 allowed the PRF to >>> depend upon the ciphersuite. TEAP requires 1.2. so the cipher >>> suite information is enough. All the cipher suites in RFC 5246 >>> use a PRF based on SHA-256. >>>=20 >>>> I think it would be surprising if the cipher suite was not >>>> obtainable. The question would be if these are ever independent >>>> of the suite there could be a problem. >>>>=20 >>>=20 >>> [Joe] I've looked at many of the libraries and they all provide a >>> mechanism to get the negotiated cipher suite. I would have to go >>> back to check to see if the provided version information. I >>> believe that many of them do. >>>=20 >>>=20 >>>> Jim >>>>=20 >>>>=20 >>>>> -----Original Message----- From: emu-bounces@ietf.org >>>>> [mailto:emu-bounces@ietf.org] On Behalf Of Joseph Salowey >>>>> (jsalowey) Sent: Thursday, November 07, 2013 4:38 PM To: >>>>> emu@ietf.org Cc: >>>>> draft-ietf-emu-eap-tunnel-method@tools.ietf.org; emu-=20 >>>>> chairs@tools.ietf.org; Stephen Farrell Subject: Re: [Emu] >>>>> Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-=20 >>>>> method-07: (with DISCUSS and COMMENT) >>>>>=20 >>>>> I'd like to hear from the working group on this. >>>>>=20 >>>>> I think Stephen is raising a fair point that trying to use the >>>>> TLS PRF in >>>> this way >>>>> creates a very tight binding between a TLS implementation and a >>>>> TEAP implementation that may make implementations difficult >>>>> depending upon the interfaces provided by a TLS library. I >>>>> think its very possible that >>>> some >>>>> libraries would not provide this information. If you think >>>>> reusing the >>>> TLS PRF >>>>> is a good idea then please state why. If you think we should >>>>> define a >>>> PRF >>>>> please indicate what approach you think we should take. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Joe >>>>>=20 >>>>>=20 >>>>> On Nov 7, 2013, at 4:15 PM, Stephen Farrell >>>>> wrote: >>>>>=20 >>>>>>=20 >>>>>> Hi Joe, >>>>>>=20 >>>>>> On 10/04/2013 05:58 PM, Joseph Salowey (jsalowey) wrote: >>>>>>>=20 >>>>>>=20 >>>>>> Apologies for the glacial response. >>>>>>=20 >>>>>> Your suggestion for point 3 looks fine. Point 1 is already a >>>>>> comment. >>>>>>=20 >>>>>> But point 2 needs a bit more discussion. >>>>>>=20 >>>>>> The concern is that you're doing a layering violation and we >>>>>> know that the layer below (TLS) is changing, possibly in a >>>>>> way that'd impact on this. Why not just pick a KDF? >>>>>>=20 >>>>>> S. >>>>>>=20 >>>>>>> On Oct 4, 2013, at 7:07 AM, Stephen Farrell=20 >>>>>>> wrote: >>>>>>>=20 >>>>>>>>=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=20 >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Stephen Farrell has entered the following ballot >>>>>>>>>> position for 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=20 >>>>>>>>>> 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 > ------------------------------------------------------------------ >>>>>>>>>> ---- >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>> DISCUSS: >>>>>>>>>> ----------------------------------------------------------------= -- >>>>>>>>>>=20 >>>>>>>>>>=20 > ---- >>>>>>>>>>=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 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 >>>>> ciphersuite. In most TLS implementations I'm aware of you can >>>>> find the ciphersuite. While this does not directly give you >>>>> the PRF it does allow >>>> you to >>>>> determine 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 ciphersuite is defined TEAP implementations would >>>>> need to make changes to support it. If the PRF is an existing >>>>> PRF then adapting to the new >>>> Ciiphersuite >>>>> is a simple addition to the mapping table which an >>>>> implementation could accommodate a configuration instead of a >>>>> code change. If a new PRF is needed then some code change is >>>>> required to adapt the new PRF. The thinking here 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 >>>>> implementation. >>>>>>>=20 >>>>>>> Is it your worry that changes in TLS 1.3 would make it not >>>>>>> possible for >>>> a >>>>> TEAP implementation to to determine which PRF to use which >>>>> would prevent interop? What sort of change are you anticipating >>>>> in TLS 1.3 that would disrupt this? >>>>>>>=20 >>>>>>>=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 >>>>>>>=20 >>>>>>> [Joe] I might be me that is confused. I was focused on the >>>>>>> MTI >>>> security >>>>> mechanism, 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: >>>>>>>=20 >>>>>>> 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): >>>>>>>=20 >>>>>>> "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. " >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Cheers, S. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> ----------------------------------------------------------------= -- >>>>>>>>>>=20 >>>>>>>>>>=20 > ---- >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>> COMMENT: >>>>>>>>>> ----------------------------------------------------------------= -- >>>>>>>>>>=20 >>>>>>>>>>=20 > ---- >>>>>>>>>>=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=20 >>>>>>>>>> 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 >>>>>>>>> authenticate the server before these peer services are >>>>>>>>> used. >>>>>>>>>=20 >>>>>>>>> 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=20 >>>>>>>>> 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=20 >>>>>>>>> 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=20 >>>>>>>>> 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=20 >>>>>>>>>> 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;-) >>>>>>>>>>=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 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=20 >>>>>>>>> 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=20 >>>>>>>>> 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 request challenge-password >>>>>>>>> field ( [RFC2985], Section 5.4.1). The >>>>>>>>> challenge-password field is limited to 255 bytes=20 >>>>>>>>> (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). >>>>>>>>>=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]=20 >>>>>>>>>> http://www.ietf.org/mail-archive/web/secdir/current/msg04106.htm= l >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 > _______________________________________________ Emu >>>>> mailing list >>>>>>>>>> Emu@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/emu >>>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>> _______________________________________________ Emu mailing >>>>> list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu >>>>=20 >>>=20 >>> _______________________________________________ Emu mailing list=20 >>> Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu >>=20 From stephen.farrell@cs.tcd.ie Wed Jan 8 17:26:05 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A568D1ADF75; Wed, 8 Jan 2014 17:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT--3fm4JjOn; Wed, 8 Jan 2014 17:26:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D561ADF0E; Wed, 8 Jan 2014 17:26:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140109012602.8084.52820.idtracker@ietfa.amsl.com> Date: Wed, 08 Jan 2014 17:26:02 -0800 Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org, emu-chairs@tools.ietf.org Subject: [Emu] Stephen Farrell's No Objection on draft-ietf-emu-eap-tunnel-method-10: (with COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 01:26:05 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-emu-eap-tunnel-method-10: 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: ---------------------------------------------------------------------- Thanks for handling my discuss. --- didn't check comments against -10 = This was discuss point (1), not a comment: (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=3Dwww.paypal.com\0.badguy.com" Even though that's really a PKI failure, not detecting it here would be bad too. older comments... - 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.) - 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? - 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. - 3.8: this says mutual auth "results" if the peer trusts the server cert belongs to the server - that sounds wrong, isn't it? - 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..." - 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;-) - The secdir review [1] raised a couple of questions that I think would be good to answer. Did I miss that answer? [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html From ietf-secretariat-reply@ietf.org Tue Jan 14 09:24:21 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06E61AE14B for ; Tue, 14 Jan 2014 09:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpUnb0cEfFtl; Tue, 14 Jan 2014 09:24:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E38541AE139; Tue, 14 Jan 2014 09:24:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140114172420.5106.2012.idtracker@ietfa.amsl.com> Date: Tue, 14 Jan 2014 09:24:20 -0800 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:24:22 -0000 State changed to Approved-announcement to be sent from IESG Evaluation::AD = Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-m= ethod/ From ietf-secretariat-reply@ietf.org Tue Jan 14 09:25:12 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA721AE149 for ; Tue, 14 Jan 2014 09:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ms-KdxJ4za6a; Tue, 14 Jan 2014 09:25:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72ED21AE139; Tue, 14 Jan 2014 09:25:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140114172508.13778.61994.idtracker@ietfa.amsl.com> Date: Tue, 14 Jan 2014 09:25:08 -0800 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:25:12 -0000 IESG has approved the document and state has been changed to Approved-annou= ncement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-m= ethod/ From iesg-secretary@ietf.org Tue Jan 14 09:25:14 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9C71AE139; Tue, 14 Jan 2014 09:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMOs-rTflU1F; Tue, 14 Jan 2014 09:25:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD4B1AE15E; Tue, 14 Jan 2014 09:25:08 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140114172508.13778.31615.idtracker@ietfa.amsl.com> Date: Tue, 14 Jan 2014 09:25:08 -0800 Cc: emu mailing list , emu chair , RFC Editor Subject: [Emu] Protocol Action: 'Tunnel EAP Method (TEAP) Version 1' to Proposed Standard (draft-ietf-emu-eap-tunnel-method-10.txt) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:25:15 -0000 The IESG has approved the following document: - 'Tunnel EAP Method (TEAP) Version 1' (draft-ietf-emu-eap-tunnel-method-10.txt) as Proposed Standard This document is the product of the EAP Method Update Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ Technical Summary This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. Working Group Summary At the start of this work there were different proposals. Through a long process the working group settled on the current approach and document. There is good consensus from the working group on this document. Document Quality This document has had review from different groups including EMU, ABFAB, NEA and RADEXT. Personnel Alan DeKok is the document Shepherd. Sean Turner is the responsible AD. From iesg-secretary@ietf.org Tue Jan 14 20:00:36 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FCB1AE18D; Tue, 14 Jan 2014 20:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.155 X-Spam-Level: X-Spam-Status: No, score=-1.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_FAIL=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnuuhvQs6nvF; Tue, 14 Jan 2014 20:00:35 -0800 (PST) Received: from nawesdniax04o.nmci.navy.mil (NAWESDNIAX04O.nmci.navy.mil [138.163.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id 252611AD986; Tue, 14 Jan 2014 20:00:35 -0800 (PST) Received: from nawesdnieg05v.nadsuswe.nads.navy.mil (Unknown_Domain [138.163.0.42]) by nawesdniax04o.nmci.navy.mil (Symantec Messaging Gateway) with SMTP id C7.A4.03442.AE516D25; Tue, 14 Jan 2014 21:00:26 -0800 (PST) X-AuditID: 8aa3014d-b7f056d000000d72-2c-52d615ea249c DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1389720326; bh=GeJ5LOL6+2ZJMJ5joNJKFct42tZsT3n4+r+47DCgFuo=; h=Content-Type:MIME-Version:Content-Transfer-Encoding:From:To: Subject:Message-ID:Date:Cc:Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:Sender; b=E+W7dcykE9waYosWLbuoE7iPi6KBnf5HFc+ERMrNnl85N968Ld/TvKHfNX27gJAOv c5XCmCJiMtfgOJfwuUz4jJ2udSV5nsIMGsBIwa/m/DCxGmTkJEnJAcLv66CvedQeFZ sJrgDA8/6G18RQ9lVv8OxzreJIyZByxjXbaeTS0s= X-Original-To: ietf-announce@ietfa.amsl.com Delivered-To: ietf-announce@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140114172508.13778.31615.idtracker@ietfa.amsl.com> Date: Tue, 14 Jan 2014 09:25:08 -0800 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.15 Errors-To: ietf-announce-bounces@ietf.org Sender: "IETF-Announce" X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-3.0 (mx1.spawar.navy.mil [IPv6:2001:480:10:1050::6]); Tue, 14 Jan 2014 09:26:11 -0800 (PST) X-SPAWAR-MailScanner-Information: Please contact the Help Desk for more information X-SPAWAR-MailScanner: Found to be clean X-SPAWAR-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0.1, required 3.5, autolearn=disabled, BOTNET_SERVERWORDS 0.00, RDNS_NONE 0.10) X-SPAWAR-MailScanner-From: ietf-announce-bounces@ietf.org X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42LpWsygpftK9FqQQedvbouO+xNZLI6tX8ti ce/MdDaLpv1f2RxYPJYs+cnk0dB2jNXjy+XPbAHMUVw2Kak5mWWpRfp2CVwZu5cJF7RwVXzb sJitgXEGRxcjJ4eEgInEk/mn2SFsMYkL99azdTFycQgJ3GKU2LD/LwtMUcOOJ4wgCRaBBhaJ xvftUAltibOrPzOC2CwCWhIn77YzQ8Q1JGasvAAU5wCy+SXWHlKGCAtJ3Fs+nQnC5pO4+OIH lJ0iMafnHpjNLKAjsWD3JzYQm1dAUOLkzCcsEHF5ie1v54CNZwMav6ClDSwuArT2xsJJYCcI C9RLvFl1Aeo0EYl3Vx8yQ5wgKbF5njBImFFATuLHscdgqwQEBCT+TQIp5wBa5Sjx6qQtxCOq Emsf72KG2FotMenIeWjwKEv8XnyeFcKWlDhz+SzYViEBcYn+Kx1gNo+At8SKqTOZQCHFI9DK KNHz5QQbRMJZ4v/LN+wgu3iATn55NHoCo84sJA/PQvLwLCQPL2BkXsWonJdYnlqckpeZWGFg opeXmFJcWlyeCmYAibJKvdzMnE2M4FTC6LuD8dpqq0OMAhyMSjy8X+y3BgmxJpYVV+YeYpTg YFYS4ZWvvxokxJuSWFmVWpQfX1Sak1p8iFGag0VJnNcsdn2QkEB6YklqdmpqQWoRTJaJg1Oq gXHx/M8L75lt7Nzg9WZjWKLF9yrVOc4r2Kxe527XuPDg1sPdQTb1e1mDnY6Uh9S0RWox1Zrt ObK19M63TPO2KSf/HWdjcuCzZJ+6Kjr7Wn1iFvOfSMVTJ9KLFyYs++Pd0XXa7EqF4qVPMl8Z ztlus/TYq5PmFB9+7w/bbZmwqL2GaxsimyZt2qbEUpyRaKjFXFScCAD9tpt+IQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA12Tb1AUdRjH+d0ex3Kyuuzx5+HUU+/Ghj+CcmMJBYFWM47Tizybccoc3bqN uzru6PbAw8ruEAHJJoZGPBiGyBMQgqgYksB8cZFEQYcEQzGCU4rpAYF1IuSA7d4edPRm59nv 83yfz/PMs4tjVE+oHGesFsZspA1KiVR8dVEtSdxnH9bs+MAbnmJz14ky0d6PS7uxF9DL0jQt Y9DnMebtTx+V6rrqZTmFUuvc506JDTnwUhSKA7kTbB23kBBHwcB4q6QUSXGK9CIYaL8cIry4 EVzpmUPCy1kEvc0zvoyYtInBPlMsFvwJ0P/p375eYjIeeseKMcFRgeDheScmFMWCo3GAK8K5 eB20uFSCTMF4wzmREK+Fa3fm/bEWqs+Mi4Q+XyGwXywUr4wxWT/hI2PkNqjt+kvCxwQZDr2V t/z6Jrg0Xe0DSzhwbWGRT4/gpvvlk3LfpDLyPZhqGvBvEAF/Dv+GCcPFQFuNjJcRqYD5qzd9 A5EkCUvlfDnOoXaDpzdd2HcrtNzsxATq21De7Q4ROqrgodMdLMQx0Pdzv49KkdHw4VAJKkOJ VQELVAUsUBWwQC3CmpDKSB9jWK1RT1uTk5OMtJbNZY8xvoB75OUnZesNXyLuiyh1okMdaLTx SRcicaQMI7wZ7RoqmM5j87NdKBUXKSOJS6ZhDbX2VZM2X0ezuiPmXAPDKhXErqkhDRW9InOE HP1relMueyTXbHAhwDFlBFF5iPMSWjr/OGM2CVYXWo+LldFE+uFWDUVm0RbmTYbJYczL2Qwc VwIx+xZnDDczWYz1db3BspxWbiG8PFcemPk/WoSHutAuPIzjP+DbEGwOnc3qs/wtNhJavkXU srra/gN6Rh5NPOJ9JF+hyzWu0OWbiXbeGhOQWO1e/ssG0Ua5jEBBQUFUGLdbtt7ih/vzv6Nw /G4IJZGKGCMZKxcbTUbGg8YQdwMZkWrm4GF6o+W/mTcQeTw40i+uhqrrOB95HodTi/UYXL82 J4bWRyVrYOnByBroK7NR0DF2QQYfnWuNhPmpxUhwVNRHQ0nVZYAlx8IG+KKvRwHOkhsKqOn8 Tgn3K7q2wpnpk4+B42xDLDRP2+OguvZkAlystidCgac8ERxOdyLUXHBvh6pT7TugYKTlCShb qEuFtvLZp6CtrzMNlrylGXDH8U0GVA5NZMJgp3uPhzuKiDvKuzeG+KNYaEvgURR7B/mj+NXV G8pt6P2kb09X2ttS0u0LB+u/LvJ0VExkPHt7k/fwS/FFBS1ZQfvjCjUnfpyMu6tOefwz9b09 32v/OLH/eGPowdnmwQbVc3FYY+cVl0d3evJo2Zz6xWGV17yeTN7XtG502yvv3P416r7Cunum +8AbioTetHvPB6uK/8mPb9rZYxo5kKlG10d/6leKWR2dHI+ZWfpfZEKGsloFAAA= X-OriginalArrivalTime: 14 Jan 2014 17:26:49.0716 (UTC) FILETIME=[CED39340:01CF114D] Cc: emu mailing list , emu chair , RFC Editor Subject: [Emu] Protocol Action: 'Tunnel EAP Method (TEAP) Version 1' to Proposed Standard (draft-ietf-emu-eap-tunnel-method-10.txt) X-BeenThere: emu@ietf.org Reply-To: ietf@ietf.org List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 04:00:36 -0000 The IESG has approved the following document: - 'Tunnel EAP Method (TEAP) Version 1' (draft-ietf-emu-eap-tunnel-method-10.txt) as Proposed Standard This document is the product of the EAP Method Update Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ Technical Summary This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. Working Group Summary At the start of this work there were different proposals. Through a long process the working group settled on the current approach and document. There is good consensus from the working group on this document. Document Quality This document has had review from different groups including EMU, ABFAB, NEA and RADEXT. Personnel Alan DeKok is the document Shepherd. Sean Turner is the responsible AD. From ietf-secretariat-reply@ietf.org Wed Jan 15 02:37:11 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50071AE343 for ; Wed, 15 Jan 2014 02:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9GZI-dJIrH9; Wed, 15 Jan 2014 02:37:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE06E1AE02E; Wed, 15 Jan 2014 02:37:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140115103710.16026.77390.idtracker@ietfa.amsl.com> Date: Wed, 15 Jan 2014 02:37:10 -0800 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 10:37:12 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-m= ethod/ From ietf-secretariat-reply@ietf.org Wed Jan 15 04:21:04 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8DB1AE373 for ; Wed, 15 Jan 2014 04:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uBiud9_B5nQ; Wed, 15 Jan 2014 04:21:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A11921AE36A; Wed, 15 Jan 2014 04:21:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140115122103.4303.48903.idtracker@ietfa.amsl.com> Date: Wed, 15 Jan 2014 04:21:03 -0800 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 12:21:04 -0000 State changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-m= ethod/ From rfc-ise@rfc-editor.org Mon Jan 20 18:20:41 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47D21A000C for ; Mon, 20 Jan 2014 18:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ombgCqmXdHJF for ; Mon, 20 Jan 2014 18:20:38 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:126c::1:15]) by ietfa.amsl.com (Postfix) with ESMTP id D835C1A000E for ; Mon, 20 Jan 2014 18:20:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c9a.amsl.com (Postfix) with ESMTP id B5172A72AC; Mon, 20 Jan 2014 18:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c9a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CBo50xuMlFE; Mon, 20 Jan 2014 18:20:27 -0800 (PST) Received: from [130.216.38.131] (nevil-laptop1.sfac.auckland.ac.nz [130.216.38.131]) by c9a.amsl.com (Postfix) with ESMTPSA id 994B4A72A4; Mon, 20 Jan 2014 18:20:26 -0800 (PST) Message-ID: <52DDD972.8080004@rfc-editor.org> Date: Tue, 21 Jan 2014 15:20:34 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Emu] ISE looking for reviewer(s) for draft-urien-eap-smartcard X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 02:20:42 -0000 Hi EMU folk: Pascal Urien submitted this draft to the Independent Stream in July 2012. It's been through four revisions since then, now I'm looking for a few reviewers. I guess I'm looking for people who understand EAP and also understand Smart Card technology. Is their anyone on the EMU list who could take a little time to read it, and send me a brief review of it, please? Alternatively, any suggestions of suitable reviewers would be much appreciated. Cheers, Nevil (Independent Submissions Editor) -- Nevil Brownlee (ISE), rfc-ise@rfc-editor.org From ietf-secretariat-reply@ietf.org Sun Jan 26 00:38:04 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1FE1A0119 for ; Sun, 26 Jan 2014 00:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64wtmEeD2q0i; Sun, 26 Jan 2014 00:38:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4954D1A0114; Sun, 26 Jan 2014 00:38:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140126083803.4461.63764.idtracker@ietfa.amsl.com> Date: Sun, 26 Jan 2014 00:38:03 -0800 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 08:38:05 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-m= ethod/ From ietf-secretariat-reply@ietf.org Wed Jan 29 02:07:41 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DA61A0229 for ; Wed, 29 Jan 2014 02:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2covRzARW4P; Wed, 29 Jan 2014 02:07:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E830A1A011B; Wed, 29 Jan 2014 02:07:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140129100739.31313.64420.idtracker@ietfa.amsl.com> Date: Wed, 29 Jan 2014 02:07:39 -0800 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 10:07:41 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-m= ethod/ From ietf-secretariat-reply@ietf.org Wed Jan 29 02:07:42 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66971A04DF for ; Wed, 29 Jan 2014 02:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggv-mux-Wvu8; Wed, 29 Jan 2014 02:07:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D481A016A; Wed, 29 Jan 2014 02:07:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140129100741.31313.14686.idtracker@ietfa.amsl.com> Date: Wed, 29 Jan 2014 02:07:41 -0800 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 10:07:43 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-m= ethod/ From ietf-secretariat-reply@ietf.org Thu Jan 30 11:05:13 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E0B1A044E for ; Thu, 30 Jan 2014 11:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV7ZqRINPYSZ; Thu, 30 Jan 2014 11:05:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 898921A044D; Thu, 30 Jan 2014 11:05:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140130190508.13871.76485.idtracker@ietfa.amsl.com> Date: Thu, 30 Jan 2014 11:05:08 -0800 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2014 19:05:13 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-m= ethod/