Sam: A new draft TEAP-03 was submitted. Please review and make sure all of your issues raised below are addressed in this draft. Thanks.
On 3/25/12 7:50 AM, "Sam Hartman" <hartmans-i...@mit.edu> wrote: > > >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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
