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

From: Sam Hartman <[email-masked]>
Date: Sun, 25 Mar 2012 07:50:45 -0400

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?

---

From: Hao Zhou <[email-masked]>
Date: Wed, 28 Mar 2012 04:06:17 -0400

Sam:

Thanks for the detailed review and comments.

After you, Joe and I got together and discussed your comments, here are what
we plan to address these comments, inline below.

> changing TLS would be to provision a key for use with a TLS preshared
[HZ] RFC5077 does have this paragraph in Section 3, which allows another
specification to define alternative mechanism to distribute the ticket:

"  Other specifications can take advantage of the session
   tickets, perhaps specifying alternative means for distribution or
   selection.  For example, a separate specification may describe an
   alternate way to distribute a ticket and use the TLS extension in
   this document to resume the session.  This behavior is beyond the
   scope of the document and would need to be described in a separate
   specification."

Based on that and the fact this alternative mechanism is optional to
implement, Sam is ok with the current draft defining this alternative
mechanism. Probably worth describing the benefits of this alternative
mechanism.

> means especially when looking at compositions.
[HZ] We discussed at length the various degrees of mutual authentication
security claim as well as resistance to MITM attacks, and agree to have a
conference all with Jim Schaad within next couple of weeks to explore and
add more descriptions and security considerations to the draft.

> anonymous TLS ciphersuites.
[HZ] See above.
 
> TLS session resumption and fall back to full vs abbreviated handshakes.
[HZ] We agreed to take look and minimize the TLS inner working description.
> Also, shouldn't the crypto binding TLV always be required here?
[HZ] We will clarify in Section 3.3.3.
> Se the new text in one of the most recent channel bindings specs for an
[HZ] We will incorporate this suggestion.

> the channel binding request  coming from the client to server.
[HZ] Peer can use Request-Action TLV with code 1 - Process TLV along with a
Channel-Binding TLV to request channel binding. Will add some descriptions.
> 3) Show how channel bindings interact with the result indications.
[HZ] Agreed that these example would help and will add them in the next rev.

> Section 3.4 needs a reference to where the concept of peer ID is
[HZ] Will add reference to RFC5247 EAP keying framework.
 
> something that we can implement here?
[HZ] Agreed that we probably need something that is immune for MITM to
fabricate. Will look into RFC5929 to see if it can be used.
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu