From stephen.farrell@cs.tcd.ie Thu Nov 7 16:15:24 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF63F21E81A8; Thu, 7 Nov 2013 16:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.674 X-Spam-Level: X-Spam-Status: No, score=-102.674 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbpxdFiCTI9t; Thu, 7 Nov 2013 16:15:20 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 10EEF21E81BA; Thu, 7 Nov 2013 16:15:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D3412BEF0; Fri, 8 Nov 2013 00:15:12 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os4NGYdYhMyr; Fri, 8 Nov 2013 00:15:11 +0000 (GMT) Received: from [31.133.184.115] (dhcp-b873.meeting.ietf.org [31.133.184.115]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 17C5ABE9C; Fri, 8 Nov 2013 00:15:09 +0000 (GMT) Message-ID: <527C2D0C.3000803@cs.tcd.ie> Date: Fri, 08 Nov 2013 00:15:08 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <20130814175831.1459.86153.idtracker@ietfa.amsl.com> <524ECB8C.5020104@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , The IESG , "" , "" Subject: Re: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:15:24 -0000 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 >>> > From jsalowey@cisco.com Thu Nov 7 16:38:14 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F095C11E80E2 for ; Thu, 7 Nov 2013 16:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.578 X-Spam-Level: X-Spam-Status: No, score=-110.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EliLfMPHZDMO for ; Thu, 7 Nov 2013 16:38:05 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6C621E811F for ; Thu, 7 Nov 2013 16:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14632; q=dns/txt; s=iport; t=1383871085; x=1385080685; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yqNXsXZvUQQVZ1HYMm+8px5D1TogELC7zVEnLXB75UA=; b=GiKeWAZHV2UyoqtM8a2EHcx21/1cvlHzHwNpYccsUEXfV5z1/gsvJLag H1oL6bxVuYQUxcASUKUIpdf6pmrlb5WUVUnFXwxyVy29tVImJ9h27Ms4P 071z2iFeh+QpWQrmTrF1MVPhClmc8784qrARDxns7iT3aqvsXlaT2Qr3l Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAGAFIxfFKtJV2Z/2dsb2JhbABRBgMBAggCgno4U75GSoEoFm0HgiUBAQEDAQEBAWQHCxACAQgYGAsLJwslAgQOBQmHcgYNvTuOEAcDBoEGMwIFDAUHgwiBEAOJCIskg2CBL5BbgWiBPoFoAgcXBhw X-IronPort-AV: E=Sophos;i="4.93,655,1378857600"; d="scan'208";a="279228833" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 08 Nov 2013 00:38:04 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA80c4ad011964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 00:38:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 18:38:04 -0600 From: "Joseph Salowey (jsalowey)" To: "emu@ietf.org" Thread-Topic: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) Thread-Index: AQHOwQsRNKCDjXOdx02v96mvaRGDcpnlF6UAgDX6AwCAAAZngA== Date: Fri, 8 Nov 2013 00:38:03 +0000 Message-ID: <5E413854-4EF4-446E-B177-686337F95744@cisco.com> References: <20130814175831.1459.86153.idtracker@ietfa.amsl.com> <524ECB8C.5020104@cs.tcd.ie> <527C2D0C.3000803@cs.tcd.ie> In-Reply-To: <527C2D0C.3000803@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.165.166] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3D6E4B7C5F31674E98528198F581CBC9@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" , Stephen Farrell Subject: Re: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:38:14 -0000 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 t= his way creates a very tight binding between a TLS implementation and a TEA= P implementation that may make implementations difficult depending upon the= interfaces provided by a TLS library. I think its very possible that som= e 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 defi= ne a PRF please indicate what approach you think we should take. =20 Thanks, Joe On Nov 7, 2013, at 4:15 PM, Stephen Farrell wrote: >=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=20 >>>>> draft-ietf-emu-eap-tunnel-method-07: Discuss >>>>>=20 >>>>> When responding, please keep the subject line intact and reply to >>>>> all email addresses included in the To and CC lines. (Feel free to >>>>> cut this introductory paragraph, however.) >>>>>=20 >>>>>=20 >>>>> Please refer to >>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html for more >>>>> information about IESG DISCUSS and COMMENT positions. >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found >>>>> here:=20 >>>>> http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ---------------------------------------------------------------------= - >>>>>=20 >>>>>=20 >>> DISCUSS: >>>>> ---------------------------------------------------------------------= - >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>> These discuss points are more questions I'd really like >>>>> answered than blocking points (depending on the answers I guess:-) >>>>> but I expect should be easily resolved. >>>>>=20 >>>>> (1) 3.4: when x.500 names or SubjectAltNames are "exported" is it >>>>> clear how those are formatted? Maybe a pointer to where that's >>>>> defined would be good in case implementers get it wrong. You might >>>>> also want to warn here (or somewhere) about names that contain a >>>>> null byte in case that attack is used e.g. with a TLS server cert=20 >>>>> subject name like "CN=3Dwww.paypal.com\0.badguy.com" Even though >>>>> that's really a PKI failure, not detecting it here would be bad >>>>> too. >>>>>=20 >>>>=20 >>>> [Joe] We could add a note about the null, is there some text in an >>>> existing document we could reuse? >>>=20 >>> That one's a comment now. >>>=20 >>>>=20 >>>>> (2) 5.2, at the end: this adds a dependency on the TLS-PRF. I >>>>> don't suppose TLS1.3 will be a big enough change for that to be a >>>>> problem, but what if it was? E.g. if someone convinced the TLS WG >>>>> to use IKE instead? Do you really need the same PRF or could you >>>>> pick one for TEAP and remove the dependency? Same question for the >>>>> MAC in 5.3. >>>>>=20 >>>>=20 >>>> [Joe] We chose to have the dependence so we would rely on the same >>>> crypto-algorithms as TLS so our crypto agility would track with TLS. >>>> We figured TLS would track advances in cryptography better than EMU. >>>=20 >>> Well, two things - if TLS 1.3 makes changes then that could mean >>> that this has to run over TLS 1.2 or earlier to get interop and >>> that seems like a bad plan. >>> And secondly, is there really a good >>> API to see what PRF has been used by TLS for a given session in >>> common TLS implementations? >>>=20 >> [Joe] The TLS 1.2 the PRF is no longer fixed and it depends upon the cip= hersuite. In most TLS implementations I'm aware of you can find the cipher= suite. 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 s= upport it. If the PRF is an existing PRF then adapting to the new Ciiphers= uite is a simple addition to the mapping table which an implementation coul= d 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 thinkin= g 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 impl= ementation.=20 >>=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 dis= rupt this? =20 >>=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 practic= e. I think ti would be good to say that if you are going to do this you mu= st 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=20 >>>> authenticate the server before these peer services are used. >>>>=20 >>>> TEAP peers MUST track whether server authentication has taken place.=20 >>>> Server authentication results if the peer trusts the provided server=20 >>>> certificate. Typically this involves both validating the certificate >>>> to a trust anchor and confirming the entity named by the certificate >>>> is the intended server. Server authentication also results when the >>>> procedures of Section 3.3 are used to resume a session in which the >>>> the peer and server was previously mutually authenticated. >>>> Alternatively, if an inner EAP method providing mutual authentication >>>> and an Extended Master Session Key (EMSK) is executed and >>>> cryptographic binding with the EMSK compound MAC is present (Section >>>> 4.2.13), then the session is mutually authenticated and peer services >>>> can be used. >>>>=20 >>>> TEAP implementations SHOULD NOT use peer services by default unless >>>> the session is server authenticated. TEAP peer implementations MUST >>>> have a configuration where authentication fails if server >>>> authentication cannot be achieved. >>>>=20 >>>> An additional complication arises when a tunnel method authenticates=20 >>>> multiple parties such as authenticating both the peer machine and >>>> the peer user to the EAP server. Depending on how authentication is >>>> achieved, only some of these parties may have confidence in it. For >>>> example if a strong shared secret is used to mutually authenticate >>>> the user and the EAP server, the machine may not have confidence that >>>> the EAP server is the authenticated party if the machine cannot trust >>>> the user not to disclose the shared secret to an attacker. In these >>>> cases, the parties who participate in the authentication need to be >>>> considered when evaluating whether to use peer services. " >>>>=20 >>>>=20 >>>>=20 >>>>> - 3.8.1: I think you need an s/MAY/MUST/ here - you say the request >>>>> "MAY be issued only ..." but I think you mean "MUST be issued >>>>> only..." >>>>>=20 >>>>=20 >>>> [Joe] Yes. How about: >>>>=20 >>>> "The peer MUST successfully authenticated the EAP server and >>>> validated the Crypto-Binding TLV as defined in Section 4.2.13 before >>>> issuing the request" >>>>=20 >>>>=20 >>>>>=20 >>>>> - 3.8.2: Just checking, and I may be wrong here. Say if I establish >>>>> a TLS server-auth tunnel and then renegotiate to get TLS >>>>> client-auth (with id privacy) as well, and then the Peer wants to >>>>> get a new cert. This calls for the tls-unique for the initial >>>>> server-auth TLS session to be used in the pkcs#10. Am I reading it >>>>> right? Is that ok? I think it is, but just want to check since its=20 >>>>> pretty confusing;-) >>>>>=20 >>>>=20 >>>> [Joe] This is meant to use the same mechanism as EST. It is >>>> currently out of sync with the latest version. It should line up: >>>>=20 >>>> In order to provide linking identity and proof-of-possession by=20 >>>> including information specific to the current authenticated TLS=20 >>>> session within the signed certification request, the peer generating=20 >>>> the request SHOULD obtain the tls-unique value from the TLS subsystem >>>> as defined in Channel Bindings for TLS [RFC5929]. The TEAP peer >>>> operations between obtaining the tls_unique value through generation >>>> of the CSR that contains the current tls_unique value and the >>>> subsequent verification of this value by the TEAP server are the >>>> "phases of the application protocol during which application- layer >>>> authentication occurs" that are protected by the synchronization=20 >>>> interoperability mechanism described in the Channel Bindings for TLS >>>> [RFC5929] section 3.1 interoperability notes. When performing >>>> renegotiation, TLS "secure_renegotiation" [RFC5746] MUST be used. >>>>=20 >>>> The tls-unique value is base 64-encoded as specified in Section 4 of >>>> [RFC4648] and the resulting string is placed in the certification=20 >>>> request challenge-password field ( [RFC2985], Section 5.4.1). The=20 >>>> challenge-password field is limited to 255 bytes (section 7.4.9 of >>>> [RFC5246] indicates that no existing cipher suite would result in an=20 >>>> issue with this limitation). If tls-unique information is not=20 >>>> embedded within the certification request the challenge-password=20 >>>> field MUST be empty to indicate that the peer did not include the=20 >>>> optional channel-binding information (any value submitted is >>>> verified by the server as tls-unique information). >>>>=20 >>>> The server SHOULD verify the tls-unique information. This ensures >>>> that the authenticated TEAP peer is in possession of the private key >>>> used to sign the certification request. >>>>=20 >>>>=20 >>>>=20 >>>>> - The secdir review [1] raised a couple of questions that I think >>>>> would be good to answer. Did I miss that answer? >>>>>=20 >>>>=20 >>>> [Joe] No, I missed the review. Response in progress. >>>>=20 >>>>> [1] >>>>> http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html >>>>>=20 >>>>>=20 >>>>> _______________________________________________ Emu mailing list=20 >>>>> Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu >>>>=20 >>=20 From ietf@augustcellars.com Fri Nov 8 11:33:58 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3499B21E81E3 for ; Fri, 8 Nov 2013 11:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBAvKmKE4l13 for ; Fri, 8 Nov 2013 11:33:53 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 939CC21E81DA for ; Fri, 8 Nov 2013 11:33:53 -0800 (PST) Received: from Philemon (dhcp-a059.meeting.ietf.org [31.133.160.89]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 9207F2CA17; Fri, 8 Nov 2013 11:33:51 -0800 (PST) From: "Jim Schaad" 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> In-Reply-To: <5E413854-4EF4-446E-B177-686337F95744@cisco.com> Date: Fri, 8 Nov 2013 11:32:29 -0800 Message-ID: <084301cedcb9$439ebca0$cadc35e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWdV5mCI1MgHcQtIBxMwxeZWdb+wHKiqCvAd/B/LYBV40d4wCHdAMzAll+1gmZTXDpsA== Content-Language: en-us 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) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 19:33:58 -0000 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? 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. 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 From hartmans@painless-security.com Fri Nov 15 10:25:12 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA46711E81F3; Fri, 15 Nov 2013 10:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DI0uy-NhYJo3; Fri, 15 Nov 2013 10:25:05 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D07B811E8225; Fri, 15 Nov 2013 10:25:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9DEFF20540; Fri, 15 Nov 2013 13:24:52 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_kKLii6DRh1; Fri, 15 Nov 2013 13:24:52 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 15 Nov 2013 13:24:52 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D20E0819E7; Fri, 15 Nov 2013 13:25:01 -0500 (EST) From: Sam Hartman To: kitten@ietf.org,emu@ietf.org, abfab@ietf.org Date: Fri, 15 Nov 2013 13:25:01 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Emu] Right place for ABFAB ephemeral keying X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 18:25:12 -0000 Hi. At the most recent ABFAB meeting I brought up the idea of adding ephemeral keying to ABFAB. This would provide the following: * Protect the EAP conversation between the peer and NAS (initiator and acceptor in GSS terms) * Provide a key to protect ABFAB negotiations * Prevent the EAP server or proxies between the EAP server and NAS from observing the resulting session This would help defeat fingerprinting by passive observers as well as minimize the damage that a passive server could do cooperating with the home EAP server. This is more valuable for ABFAB used in protocols like NFS and CIFS or in RFc 4462 SSH key exchange than it is for ABFAB used within an TLS session for IMAP, XMPP or SMTP. Stephen thought the general idea of protecting ABFAB sounded good but would prefer that we get better protocol re-use and suggested we look into protecting EAP in general. I was dubious of that but suggested protecting Kerberos GSS in general as an option. After trying to work through how to protect either EAP or Kerberos, I've mostly concluded that I don't know how to get significant protocol re-use. However I do agree with Stephen that it would be better that get protocol re-use if we can still implement relatively quickly and meet all of the above protection goals for ABFAB. So, here are my thoughts on EAP and Kerberos: EAP. Ephemeral keying doesn't belong in an EAP method. EAP methods run between the peer and EAP server. We want PFS between the peer and NAS. The endpoints are wrong. We could insert a layer similar to ERP (the hokey produced EAP Reauthentication Protocol) between the peer and NAS. It's been a while since I've looked at ERP, but I seem to recall that ERP runs between the peer and an entity in the visited domain although it does have specific NAS support. That approach would be OK for ABFAB assuming it could be implemented efficiently. It would be a bit ugly because you want to start using the ephemeral key well before EAP has concluded. However, for lower layers that do complex keying after EAP concludes, it's probably the wrong approach. Also, ERP took a long time to specify. I don't want to commit to astandardization effort that complex. Kerberos. I was considering trying to share some tokens for ephemeral keying with Kerberos. keying wants ephemeral keing within a GSS mechanism. You could do that for Kerberos, although you'd need to take advantage of the not-widely-implemented extension to the magic checksum used by GSS for channel binding and (in that magic extension) other extensions. In ABFAb the framing would be different because our context tokens have subtokens. However we could use the same PDU. Except for two things. First, Kerberos probably would be happier with an ap-req and ap-rep extension than a GSS mechanism level extension. Secondly, Kerberos might well want to use pkinit data structures and possibly even run a stripped down client-server version of pkinit for the ephemeral keying. That's way too expensive in terms of implementation complexity if you don't already have a pkinit implementation sitting around. my conclusion from all this is that the right place to do ephemeral keying for an EAP protocol is in the lower layer and that unless I got something wrong or missed an alternative, ABFAb should do its own mechanism. Can anyone see a good way to get protocol re-use here? From jsalowey@cisco.com Sun Nov 17 20:34:27 2013 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1298E11E8460 for ; Sun, 17 Nov 2013 20:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHihIF51UJi7 for ; Sun, 17 Nov 2013 20:34:22 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 136CC11E845F for ; Sun, 17 Nov 2013 20:34:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16982; q=dns/txt; s=iport; t=1384749261; x=1385958861; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KDuWOaTZjFLV956kl/tXKza+crBZ5GXTQnZF9V742Zo=; b=kD6MRoRzDdZFrB/oSRqlyNoD3z7oJhuwYcXWRjNQY09RwhO/t5pL53y5 SmtgRda00iM3ZIIF+KojZjhLEXCBn1pFxIu/CWz5M1yRCTw6fQsVOJSWg hO+5FhyqXyda9IA7qWsp+QKfBcUytnM/XvtTv+cdk1eiRbn1YjbaJpITa 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAFGYiVKtJXG9/2dsb2JhbABQBgMBAggCgno4U75hS4EUFnSCJQEBAQMBAQEBNy0HCwUHBAIBCA4DBAEBARgGBQQHJwsUCQgCBA4FCYdyBg3BDxeOHQcDBgIBgQYzAgUGBgUHgwiBEQOULoNigS+QXoFqgT6BaAIeBhw X-IronPort-AV: E=Sophos;i="4.93,720,1378857600"; d="scan'208";a="285542428" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 18 Nov 2013 04:34:20 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAI4YJqW021744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 04:34:19 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Sun, 17 Nov 2013 22:34:19 -0600 From: "Joseph Salowey (jsalowey)" To: Jim Schaad Thread-Topic: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) Thread-Index: AQHOwQsRNKCDjXOdx02v96mvaRGDcpnlF6UAgDX6AwCAAAZngIABPPWAgA68XIA= Date: Mon, 18 Nov 2013 04:34:18 +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: <084301cedcb9$439ebca0$cadc35e0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.87] Content-Type: text/plain; charset="us-ascii" Content-ID: <4A2FC0F1ADEF0D4C8F26874FD2F90305@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , Stephen Farrell Subject: Re: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 04:34:27 -0000 On Nov 8, 2013, at 11:32 AM, Jim Schaad wrote: > Looking for a piece of information. >=20 > Are there cases in TLS before 1.3 where the PRF and the MAC are not infer= red > from the cipher suite that was negotiated? >=20 [Joe] You would need to know both the cipher suite and the TLS version numb= er 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 th= e 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. T= he > 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 mechanis= m to get the negotiated cipher suite. I would have to go back to check t= o see if the provided version information. I believe that many of them do.= =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-tunne= l- >> 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 i= n > this way >> creates a very tight binding between a TLS implementation and a TEAP >> implementation that may make implementations difficult depending upon th= e >> 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 >>>> >>>> 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 allo= w > 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 ne= w >> ciphersuite is defined TEAP implementations would need to make changes t= o >> 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 fo= r > 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 >>>>> 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 From Josh.Howlett@ja.net Thu Nov 28 03:52:24 2013 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 A20DF1AE0D1; Thu, 28 Nov 2013 03:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 Dueuhi522cT3; Thu, 28 Nov 2013 03:52:21 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 907CF1AE0CF; Thu, 28 Nov 2013 03:52:21 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0A5544A6BA0_2972E74B; Thu, 28 Nov 2013 11:52:20 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id A21944A6B1C_2972E72F; Thu, 28 Nov 2013 11:52:18 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Thu, 28 Nov 2013 11:52:18 +0000 From: Josh Howlett To: Sam Hartman , "kitten@ietf.org" , "emu@ietf.org" , "abfab@ietf.org" Thread-Topic: [Emu] Right place for ABFAB ephemeral keying Thread-Index: AQHO4jAYN1MIKnIBekG46BO4ULt9e5o6nCiA Date: Thu, 28 Nov 2013 11:52:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <8687A9390B2F9F429FD8BEC1958F0720@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Emu] Right place for ABFAB ephemeral keying 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, 28 Nov 2013 11:52:24 -0000 Sam, I agree with your conclusion. There are example of lower layers using EAP-based ephemeral keying, and ABFAB could perhaps look to those for inspiration and perhaps reuse. Josh. On 16/11/2013 02:25, "Sam Hartman" wrote: > >Hi. >At the most recent ABFAB meeting I brought up the idea of adding >ephemeral keying to ABFAB. >This would provide the following: > >* Protect the EAP conversation between the peer and NAS (initiator and > acceptor in GSS terms) > >* Provide a key to protect ABFAB negotiations > >* Prevent the EAP server or proxies between the EAP server and NAS from > observing the resulting session > >This would help defeat fingerprinting by passive observers as well as >minimize the damage that a passive server could do cooperating with the >home EAP server. This is more valuable for ABFAB used in protocols like >NFS and CIFS or in RFc 4462 SSH key exchange than it is for ABFAB used >within an TLS session for IMAP, XMPP or SMTP. > > >Stephen thought the general idea of protecting ABFAB sounded good but >would prefer that we get better protocol re-use and suggested we look >into protecting EAP in general. I was dubious of that but suggested >protecting Kerberos GSS in general as an option. > >After trying to work through how to protect either EAP or Kerberos, I've >mostly concluded that I don't know how to get significant protocol >re-use. However I do agree with Stephen that it would be better that >get protocol re-use if we can still implement relatively quickly and >meet all of the above protection goals for ABFAB. > >So, here are my thoughts on EAP and Kerberos: > >EAP. Ephemeral keying doesn't belong in an EAP method. EAP methods run >between the peer and EAP server. We want PFS between the peer and NAS. >The endpoints are wrong. > >We could insert a layer similar to ERP (the hokey produced EAP >Reauthentication Protocol) between the peer and NAS. It's been a while >since I've looked at ERP, but I seem to recall that ERP runs between the >peer and an entity in the visited domain although it does have specific >NAS support. > >That approach would be OK for ABFAB assuming it could be implemented >efficiently. It would be a bit ugly because you want to start using the >ephemeral key well before EAP has concluded. However, for lower layers >that do complex keying after EAP concludes, it's probably the wrong >approach. Also, ERP took a long time to specify. I don't want to >commit to astandardization effort that complex. > >Kerberos. I was considering trying to share some tokens for ephemeral >keying with Kerberos. keying wants ephemeral keing within a GSS >mechanism. You could do that for Kerberos, although you'd need to take >advantage of the not-widely-implemented extension to the magic checksum >used by GSS for channel binding and (in that magic extension) other >extensions. In ABFAb the framing would be different because our context >tokens have subtokens. However we could use the same PDU. > >Except for two things. First, Kerberos probably would be happier with >an ap-req and ap-rep extension than a GSS mechanism level extension. >Secondly, Kerberos might well want to use pkinit data structures and >possibly even run a stripped down client-server version of pkinit for >the ephemeral keying. That's way too expensive in terms of >implementation complexity if you don't already have a pkinit >implementation sitting around. > >my conclusion from all this is that the right place to do ephemeral >keying for an EAP protocol is in the lower layer and that unless I got >something wrong or missed an alternative, ABFAb should do its own >mechanism. > >Can anyone see a good way to get protocol re-use here? >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www.ietf.org/mailman/listinfo/emu Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238