Subject: Security concerns with PPP-EAP-TLS

From: Jonathan Herzog <[email-masked]>
Date: Fri, 04 Aug 2000 12:45:35 -0400

Below is an excerpt from a short report on the security of EAP-TLS. The
full report will be available, sometime next week, at 

http://www.mitre.org/support/papers/

(The rest of the report is merely background and unnecessary for those
familiar with both TLS and EAP.) Comments invited.
------------------------------------------------------------------

Some Security Concerns Regarding PPP--EAP--TLS
(Copyright 2000 The MITRE Corporation. All Rights Reserved.)
MP 00B0000019

Jonathan Herzog
[email-masked]

4. TLS in PPP

In RFC 2716, it is recommended that TLS be added to the authentication
mechanisms available for use in PPP, and suggests a way in which TLS can
be embedded within EAP.  In fact, this embedding is very simple: TLS
already specifies the formats that its messages take, so these messages
are simply sent as the data of PPP packets.  

In PPP--EAP--TLS, TLS is executed only until the end of the first run of
the Handshake protocol.  At that point, the authentication has finished,
the shared secret has been exchanged, and the underlying Record protocol
has been initialized and is providing a secure tunnel. In PPP, however
the authentication phase and the encryption phase are distinct; all that
PPP requires from TLS is authentication and a shared secret. Hence, the
secure tunnel provided by TLS is abandoned, and the shared secret stored
for use by ECP. 

Although PPP does not guarantee reliability, this does not seem to
compromise the security of TLS. (In fact, since TLS is designed to be
secure against active attacks (i.e., those that disrupt or forge
messages), vulnerability to packet loss would indicate a serious design
flaw.) What could be troubling, however, is the fact that PPP is a
peer-to-peer connection while TLS is based on a client-server model. 
Except for PPP--EAP--TLS, all EAP protocols provide authentication in
one direction only. Two simultaneous authentication protocols,
therefore, would not conflict.  TLS, however, can provide mutual
authentication, and it is unclear what should happen when it is
requested by both sides.

The desirable behavior, of course, would be for both requests to
collapse into a single run of the protocol, using mutual authentication.
However, the specification seems to allow the possibility of two
independent runs of TLS. If this happens, then at their completion the
PPP connection will have two separate shared secrets and two (possibly
distinct) cryptosuites.  PPP--EAP--TLS specifies how one shared secret
is used to generate the keys necessary for ECP, but not how to pick
which of the two shared secrets or cryptosuites are to be used.

Another related oddity is that the role of the authenticator in
PPP--EAP--TLS does not map directly to the role of authenticator in
other authentication protocols.  Elsewhere, the authenticator is the one
receiving the authentication; the peer proves its identity to the
authenticator.  But in PPP--EAP--TLS, the authenticator takes on the
role of server, and as mentioned above, it is possible for
authentication in TLS to be server--to--client only.  And while in
PPP--EAP--TLS (as opposed to TLS) the client is required to authenticate
itself when the server requests such, the server is not required to
request.  So, the authenticator can now request an authentication
mechanism by which it is authenticated to the peer but not vice versa.

Also, there appears to be a large disconnect between PPP--EAP--TLS and
ECP.  During PPP--EAP--TLS, the client and server negotiate a set of
cryptographic algorithms, and according to the specification, any
subsequent run of ECP is required negotiate those same algorithms. This
raises several potential sources of concern, however.

1) First, all cryptosuites defined in TLS require that a keyed MAC be
added whenever encryption is used. However, none of the encryption
algorithms defined for ECP have any type of integrity check. It is
therefore impossible for ECP to negotiate the exact cryptosuite which
was agreed upon in TLS. This is easily fixed by defining ECP protocols
to match the TLS cryptosuites, but no such protocols are defined at this
time.
  
2) Even if ECP performs the most natural action and uses the encryption
algorithm from the TLS cryptosuite, problems remain. ECP is designed to
be extensible; theoretically, ECP can negotiate any algorithm mutually
acceptable to both parties. However, TLS is not similarly extensible;
the list of cryptosuites available to TLS are enumerated in the
specifications, and to use any cryptosuites not on that list would mean
either revising or deviating from the standard. In other words,
compliant implementations of ECP will no longer be able to use private
or proprietary algorithms when EAP--TLS is used for authentication.
  
3) Lastly, this requirement---that ECP use the algorithm negotiated in
TLS---potentially undermines the basic design of PPP. In the original
design of PPP, authentication and encryption are negotiated and enacted
in separate phases. If TLS is used as proposed, however, the negotiation
of encryption has been transplanted from ECP to the earlier phase of
EAP. While this may not necessarily introduce any weaknesses, it does
significantly change the design of PPP.

5. Summary and Suggestions

The use of TLS as an authentication mechanism is an excellent idea.
However, some minor issues should be addressed before it should be used.
In particular, it would be advisable for the authenticator to play the
role of client (rather than server), to bring EAP--TLS into concordance
with the way those roles are used in other EAP protocols.

Also, the specification should resolve the ambiguity that results when 
both sides request TLS. It would be simpler to require that both
requests be merged into a single run of the protocol, but if the
specification wishes to allow simultaneous runs it should describe how
to choose between the resulting secrets and cryptosuites.

Lastly, EAP--TLS raises three concerns about ECP:

* First, EAP--TLS relocates cryptosuite negotiation from ECP to EAP.
While this may be a change for the better, it is still a significant
alteration to the design of PPP and may deserve further consideration.

* Second, it highlights the fact that no defined ECP protocol includes a
keyed MAC for integrity. While this is not a problem caused by EAP--TLS,
it is still serious enough to warrant note.

* Third, it prohibits ECP from using any cryptosuite that cannot be
negotiated in TLS, including all private algorithms.

The solution to the last two concerns above would seem simple and
two-fold. First, ECP cryptosuites that include integrity protection
should be defined. Ideally, these would include all the cryptosuites
defined in the TLS specification. Second, the list of cryptosuites
available to TLS should be expanded to include all ECP cryptosuites. The
TLS specifications explicitly allows subsequent standards to expand the
list of cryptosuites; the EAP--TLS specification should map ECP
cryptosuites to a set of TLS cryptosuites which may only be available
during EAP--TLS.

-- 
Jonathan C. Herzog  |  business: [email-masked]  |  "Television is
#include<witty.sig> |  pleasure: [email-masked]  |    furniture."