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 algorithms negotiated in the underlying TLS session. Since these algorithms depend on the TLS version and cipher suite, TEAP implementations need a mechanism to determine the version and cipher suite in use for a particular session. The implementation can then 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 <[email protected]> wrote: > > 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 <foo,bar> 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) >> <[email protected]> wrote: >> >>> >>> On Nov 8, 2013, at 11:32 AM, Jim Schaad <[email protected]> >>> 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: [email protected] >>>>> [mailto:[email protected]] On Behalf Of Joseph Salowey >>>>> (jsalowey) Sent: Thursday, November 07, 2013 4:38 PM To: >>>>> [email protected] Cc: >>>>> [email protected]; emu- >>>>> [email protected]; 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 >>>>> <[email protected]> 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 >>>>>>> <[email protected]> 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 >>>>>>>>> <[email protected]> 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 >>>>>>>>>> [email protected] >>>>>>>>>> https://www.ietf.org/mailman/listinfo/emu >>>>>>>>> >>>>>>> >>>>> >>>>> _______________________________________________ Emu mailing >>>>> list [email protected] https://www.ietf.org/mailman/listinfo/emu >>>> >>> >>> _______________________________________________ Emu mailing list >>> [email protected] https://www.ietf.org/mailman/listinfo/emu >> _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
