Subject: Re: [Emu] Review of draft-ietf-emu-eap-tunnel-method

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Thu, 26 Jul 2012 20:00:30 +0000

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" <[email-masked]> 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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/emu