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
