1) TEAP extends TLS RFC 5077
In section 2, TEAP discusses using phase 2 TLVs to include a TLS session ticket and an associated secret key. RFc 5077 only permits session tickets to be sent using the session ticket message. I believe that this is an extension to TLS that would need to go through the TLS working group. My preference is to remove TLS tickets sent via a manner other than the session ticket handshake message. If support for this is needed a better solution that does not involve changing TLS would be to provision a key for use with a TLS preshared key ciphersuite. 2) TEAP server is separate architectural element from inner server So, in section 2 the document says that the TEAP server and inner server are separate architectural elements. However, in section 1 a design goal was avoiding MITM attacks. To meet that goal and to have an architecture where these servers are separate, a lot more clarity is required around what a MITM is and what is an acceptable intermediate. I also suspect significant security analysis will be required on this point. Let's start by coming up with a clear definition of what a MITM is for this protocol and work from there. Section 7.3 is inadequate. It does not clearly explain who is involved in the trust relationship. IN particular, does the peer need to trust the intermediate, or do the inner servers need to trust the intermediate or both? I think it depends for different vulnerabilities. In order to understand the architectural implications of this I'd like to ask those who want to support this architectural separation to go through every reference to MITM or man-in-the-middle or mutual authentication in the document. For each reference, answer the following questions: A) Who is negatively affected if the attack is possible or the security claim not maintained? (eap server, peer, intermediate, combination) B) for security claims especially those about inner methods. Which parties need to confirm the claim in order to avoid the harm identified in A above? I also think we need clarity around mutual authentication and what that means especially when looking at compositions. 3) Section 3.2: resistance to MITM attack The specification refers to inner methods providing resistance to man-in-the-middle attacks as if this is an RFC 3748 security claim. I assume this refers to the discussion in section 7.4 of RFC 3748. I don't think that claim is strong enough to provide secure composition of inner methods with anonymous ciphersuites. This is related and possibly a superset of the problems discussed in draft-hartman-emu-mutual-crypto-binding). Clearly checking the certificates is an inadequate solution for anonymous TLS ciphersuites. 4) Section 3.2.2: overly much detail on TLS workings I think that having something called a PAC which is really just a TLS session ticket is undesirable. I don't think we need a new name for TLS concepts we're reusing. I am concerned that we specify so much information about how TLS session resumption works. What if future versions of TLS change that? What if our spec is inconsistent with TLS? I recommend we remove most of the information about server and client TLS session resumption and fall back to full vs abbreviated handshakes. 5) Section 3.3.3: confused I'm confused when I read section 3.3.3 on protected negotiation indication. I don't understand when an intermediate result TLV is or is not required for the peer and server. Also, shouldn't the crypto binding TLV always be required here? 6) Section 3.3.3: please require peers reject EAP success without protected negotiation. I think it is very important that we mandate peers implementing TEAP MUST not treat an EAP success packet prior to the peer and server reaching protected result indication as successful. When peers do this (as many do with existing methods) it permits several bid-down attacks. Se the new text in one of the most recent channel bindings specs for an example. 7) Section 3.3.3: How does a peer do channel binding What should a peer do if it wishes to perform channel binding and server sends back a protected success? Request-action seems inefficient for this because the first message is the channel binding request coming from the client to server. 8) Examples with section 3.3 I think that section 3.3 could benefit from several examples: 1) A peer wishes to use a client certificate but wishes to hide its identity and thus use renegotiation. The server requests some inner method in the first phase 2 message before the client can start renegotiation at TLS. Show an example flow of how this works out and how the parties get back in sync. 2) A peer wishes to use an inner eap method even when the server is happy to offer success in the first message. Show how many result indications are required. 3) Show how channel bindings interact with the result indications. 8) Section 3.4: what is a peer ID? Section 3.4 needs a reference to where the concept of peer ID is defined. 9) Section 3.5: session ID First, you need a reference to what an EAP session ID is. second, do TLS implementations really make this value available? The text is unclear how this interacts with session resumption. I'd like to start by understanding whether we want the session ID to change for session resumption. I wonder if using something we've already standardized like the construction in section 3 of RFC 5929 would be a better choice for something that we can implement here? _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
