use_tunneled_reply overwrites username with PEAP, doesn't do that with TTLS

[qnet-herwin]

Compiled from branch 3.0.x, HEAD c8a7f78296733db1afbcfeaa76623b79153e7993

Some really basic changes in eap.conf, in the sections ttls and peap:

• use_tunneled_reply changed to yes
• virtual_server changed to proxy-inner-tunnel

And enabled the proxy-inner-tunnel virtual server. Added a user bob with password hello in users (or actually: removing the comment), it doesn't matter if you add extra attributes to the user.

The following configs for eapol_test have been used:

network={
    ssid="example"
    key_mgmt=WPA-EAP
    eap=TTLS
    identity="bob"
    anonymous_identity="anonymous"
    password="hello"
    phase2="auth=PAP"
}

network={
    ssid="example"
    key_mgmt=WPA-EAP
    eap=PEAP
    identity="bob"
    anonymous_identity="anonymous"
    password="hello"
    phase1="peapver=0"
    phase2="auth=MSCHAPV2"
}

Both the output of eapol_test and tcpdump show that with TTLS, the User-Name in the Access-Accept is still anonymous, but with PEAP, the User-Name has been changed to bob. All Access-Requests send the User-Name anonymous.

Intuitively, I would say the behaviour of TTLS is the correct one.

[alandekok]

If you set "use_tunnelled_reply = yes", that means the User-Name from the tunnelled reply should be used in the reply.

The EAP module in the inner-tunnel should set it's reply to have "User-Name = bob". Which should then be copied to the outer tunnel.

I think the behavior of PEAP is correct for how the code is documented as working.

But I think the "use_tunneled_reply" configuration shouldn't over-write the outer User-Name. That should be:

• taken from whatever the outer session set it to be
• or, take from the outer request:User-Name

[qnet-herwin]

Just had a fresh look at the issue. If we change the users file to set an attribute User-Name in the reply, the behaviour of TTLS and PEAP is equal.

By looking at the debug logging, it appears to me that every EAP module tries to add the known User-Name in the reply, unless the reply already has one. So for TTLS, the reply that includes a User-Name is untouched, otherwise the value of the outer user is added. Or maybe it always tries to add the current User-Name to the reply, and then overwrites it with the value of the inner-reply. The external behaviour is the same. For PEAP, the inner tunnel is EAP-MSCHAPv2. This tunnel contains the complete inner user, so this value is copied to the reply. The PEAP module finds a User-Name in the inner reply and copies it to the outer reply.

[alandekok]

See commit fa96111330 and ec1832c . You can now cache attributes across multiple packet exchanges. This feature should be used in preference to the "use_tunneled_reply" stuff.

[qnet-herwin]

I like the idea of that, but it doesn't seem to be working.

I created a clean 3.0.x install, with the following changes

• Disable openssl version checks (debian)
• Enabled the user bob with password hello
• Updated the inner-tunnel.authorize to include the user-name in the outer.session-state
• Updated the inner-tunnel.post-auth to overwrite the user-name in the outer.session-state (just for testing purposes)
• Updated default.post-proxy to add outer-state vars to reply (it was already included in default.authorize)

Tried connecting with eapol_test, the full debug log is on https://gist.github.com/qnet-herwin/56c25efdd55d629f8496

A number of things that surprised me:

• At line 2655 a check is done to see if the the user-name exists in outer.session-state. This is the first packet from inside the tunnel, so it doesn't exist. It adds it to outer.session-state
• At line 2844 the next packet inside the tunnel is handled. Here it thinks that the user-name is not added to outer.session-state, (if (!outer.session-state:User-Name) -> TRUE), so it tries to add it again. At every packet it thinks that outer.session-state:User-Name doesn't exist.
• At line 2132 the value is overwritten with a dummy value. This is the same packet as the last packet in authorize, so here the value is overwritten (this statement was just added as a test, not really relevant for the case itself)
• At line 3281 it shows that there is no information to cache (not sure if this is relevant)
• At line 3289 it tries to add session-state to reply, but it's empty again.

Some other tests I did also resulted in the situation that the values were cleared with every packet in the same session.

[alandekok]

I've pushed some fixes to the session-state code. Your example above should now work

[qnet-herwin]

Yup, it's working now. Since this gives enough building blocks to solve the original problem, I'm closing this issue now.