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

[Axel Luttgens]

Le 30 août 2014 à 16:23, Alan DeKok a écrit :

> 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.

Hello Alan,

Many thanks for your helpful reply.

Yes, I ended to suspect the "update outer.reply" mechanism to be somewhat too simplistic, allowing to satisfactorily handle only a subset of authentication methods.

And thus was of the intent to ask another set of questions.
Since opportunity makes thieves...

Could it be said that, as a general rule, the best approach for retrieving information from the inner tunnel is to make use of "use_tunneled_reply = yes"? Conversely, are there particular cases for which that approach won't work?

On the other hand, nothing coming for free, does "use_tunneled_reply = yes" significantly increase the load on the server, with perhaps the risk to use too much resources?

Finally, in the case of error (a non existing user, for instance), there seems to be no attempt to pass the saved attributes to the "Post-Auth-Type REJECT" section. Am I right?

Axel