Subject: comments on draft-josefsson-pppext-eap-tls-eap-01.txt

From: Bernard Aboba <[email-masked]>
Date: Mon, 12 Nov 2001 11:57:45 -0800 (PST)

Section 3.1, second paragraph

"Accordingly, it should not be used instead of the peer identity sent
inside the TLS channel later on."

From this sentence, it is not clear exactly what it "should not be
used" for. In practice, the EAP-Identity/Response is put into the
RADIUS User-Name attribute in the Access-Request and used in routing
requests to the correct backend server. So if there is no Identity
exchange, then termination of the EAP conversation must occur at the
proxy. 

I don't think you want to require this. With EAP TLS, we required that
the identity returned in the EAP Response be the same  as the identity
claimed in TLS, if both are present. 

In practice, if they were not the same, there is the possibility that
authentication has been routed to the wrong backend server, so you
wouldn't want to continue. 

Within PEAP, it would appear that there is the potential for multiple
identities: the initial EAP Response Identity, possibly another EAP
Response Identity inside the TLS channel, and possibly another 
identity included within an EAP exchange (e.g. EAP TLS has this). 

So you need to be clear on how these identities are to be processed and
compared. Some thoughts:

1. The first EAP Response/Identity is typically placed inside the RADIUS
User-Name attribute, and used to route the exchange to the backend
authentication server. In PEAP, this identity is not authenticated, so you
have no way of verifying it. 

2. The second EAP Response/Identity inside the TLS channel is
authenticated by the tunneled EAP method. I would recommend that this be
checked against the first EAP Response/Identity, and if they don't match,
then the authentication should be aborted. 

3. Subsequent EAP authentications may occur within the tunnel. These may
authenticate alternate identities (e.g. machine auth vs. user auth), and
so those subsequent identities may not match the first two. 

Section 3.1, bullet 5. 

change "must NOT send any certificate request" to "MUST NOT send any
certificate request."

Section 3.1, paragraph after bullet 8.

"Note that it is not until now that we deviate from the TLS EAP
specifiation."

Actually, the deviation occurs in bullet 5 -- in EAP TLS the authenticator
SHOULD send a certificate request, and here it MUST NOT. 

Section 3.1, second paragraph after bullet 8

"This concludes the mutual authentication and upon success both
authenticator and peer may generate any amount of new key material to be
forwarded to the underlying transport."

Actually, PEAP constitutes two one-way auths, not a single mutual
authentication. In the TLS exchange, the Authenticator is authenticated
via its certificate; in the second EAP method the client is authenticated
(at a minimum). 

The statement about "new key material" is somewhat vague. Does this refer
to the TLS master key? If so, this was derived prior to the tunneled EAP
exchange. Or does it refer to the TLS session keys which are derived from
the TLS master key? Or does it refer to an additional key generated within
the tunneled EAP method? It is not clear which key is to be used here, and
that could cause interoperability problems. 

The distinction is quite important, I think. If the key is the initial TLS
master key, then posession of this key by a client (as proved in session
resumption) does not prove the client was previously authenticated. It
would be possible to obtain such a key after failing the tunneled
authentication. If it represents the key derived in the tunneled EAP
method, then only EAP methods deriving keys could be used with PEAP, which
seems like an unnecessary restriction. So it seems that the term "new
key" is not really appropriate here.

Section 3.1, last paragraph.

"It remains to be described what happens upon failures. In case the TLS
negotiation has failed fatally (after the proper TLS Alert messages have
been sent), an EAP-Failure message is transmitted within the TLS channel,
in the second EAP handshake, after any EAP-Success and EAP-Failure
messages has been successfully sent, the same type of packet should be
send in the outer EAP channel as well."

I would advocate that the same error strategy be used as in RFC 2716. Note
that sending two EAP Failure or Success messages may not be feasible,
since client state machines will terminate on the first Failure/Success
message and these messages are not ACK'd. So how do you send the second
message? There is may be no way to continue the EAP conversation after
that point! In practice, this may be a case where you send the
Success/Failure inside of the TLS tunnel, get a response of an EAP PEAP
"start" message with null body, then have the backend server send a RADIUS
Access Accept/Reject with an EAP-Message Success/Failure attribute inside. 
This lengthens the conversation by a round-trip, so it would be great to
get around this somehow, but I can't see how off the top of my head right
now. 

Section 6. 

I think you need to talk about the security issues involved in
TLS session resumption. TLS resumption can occur based on the
Authenticator's TLS session cache, which has no relationship to successful
tunneled EAP auth. So if a PEAP client successfully resumes a session,
this is NOT sufficient to allow access without another tunneled
authentication. The client could have obtained a TLS master key, and then
flunked subsequent tunneled EAP auth -- but would still be able to resume
the TLS session, based on proving posession of the master key!

So it seems to me that tunneled EAP needs to be done whether the TLS
session was resumed or not. 

Also, because the TLS master key is derived between the endpoints and
typically cannot be recovered from the TLS channel layer via an
appropriate API call, resumption must occur by forwarding the
authentication to the original backend authentication server. A proxy
located nearby cannot handle the resumption unless was the endpoint in the
original TLS conversation as well.