Not able to receive inner identity in Access-Accept in EAP-TTLS.

Alan DeKok aland at
Sat Aug 30 16:23:14 CEST 2014

Axel Luttgens wrote:
> Starting with raddb as created at compile time:
> 	- uncomment the entry for "bob" in the users file
> 	- uncomment the "update outer.reply" section in file inner-tunnel
> Call eapol_test with:
> 	- eap=TTLS
> 	- phase2="auth=MSCHAPV2"
> It appears that the reply comes with the outer identity ("anonymous"), not the inner one ("bob").
> (see output "WITH update outer.reply" hereafter)

  Unfortunately, that is how it works.  If you read the debug output,
for the last few packets, you will see the inner tunnel being
executed... the outer reply being updated, and then ANOTHER packet comes
from the client.  For this last packet, the inner tunnel is NOT
executed.  So the "update outer.reply" does NOT get executed, and the
User-Name is never set.

  The issue is that the server treats each packet as separate.  You've
updated outer.reply for packet X.  That's nice, but packet X is an
Access-Challenge.  Then packet X+1 is an Access-Accept, but you're *not*
updating the reply.  So it doesn't get set.

  Read the debug output.  It says:

(7)  eap_ttls : Using saved attributes from the original Access-Accept
(7)  WARNING: eap_ttls : No information to cache: session caching will
be disabled for session

  There are NO attributes printed out after the first message.  So NO
attributes will be saved.

> Let's then change FR's config:
> 	- in file inner-tunnel, replace "outer.reply" with "reply"
> 	- set use_tunneled_reply to "yes" in file eap
> Call eapol_test with the same settings as above.
> The reply now comes with the inner identity.
> (see output "WITH update reply / use_tunneled_reply=yes" in my next message)
> If someone could provide the rationale, I am very interested. :-)

  In this case, the server caches the attributes in the Access-Accept,
and uses them for the outer reply.  This action is PROTOCOL AWARE.

  i.e. it knows when to do the right thing.

  A blind "update outer.reply" is NOT protocol aware, and will sometimes
do the wrong thing.

  Alan DeKok.

More information about the Freeradius-Users mailing list