[defect]: User-Password not set in authorize block when using EAP-GTC

[andredigenova]

What type of defect/bug is this?

Non compliance with a standards document

How can the issue be reproduced?

1. Configure EAP-TTLS with GTC as the inner method.
2. Try to access User-Password in the authorize for the inner-tunnel

if (&User-Password) { noop }

3. Password isn't there.

Possibly related to #2268.

The User-Password attribute is inaccessible/not present in the authorize block when using EAP-GTC contrary to documentation.

This breaks a few downstream things as well like the mods-enabled/cache_auth mod which relies on the password for a cache key.

Log output from the FreeRADIUS daemon

(6) suffix: Checking for suffix after "@"
(6) suffix: No '@' in User-Name = "andre", looking up realm NULL
(6) suffix: No such realm "NULL"
(6)       [suffix] = noop
(6)       if (&User-Password) {
(6)       if (&User-Password)  -> FALSE
(6)       update control {
(6)         &Proxy-To-Realm := LOCAL
(6)       } # update control = noop

Relevant log output from client utilities

No response

Backtrace from LLDB or GDB

No response

[alandekok]

The User-Password attribute is inaccessible/not present in the authorize block when using EAP-GTC

Yes, because EAP-GTC doesn't supply a User-Password attribute.

contrary to documentation.

Which documentation says that?

[andredigenova]

The User-Password attribute is inaccessible/not present in the authorize block when using EAP-GTC

Yes, because EAP-GTC doesn't supply a User-Password attribute.

contrary to documentation.

Which documentation says that?

mods-enabled/eap

The plain-text response which comes back is put into a User-Password attribute, and passed to another module for authentication. This allows the EAP-GTC response to be checked against plain-text, or crypt'd passwords.

[mcnewton]

I just tested this and it works as described. The password is available in the authentication section, not in the authorise section.

Configuration questions belong on the freeradius-users list.

[andredigenova]

The documentation suggests it should be available in the authorize section -- otherwise cache_auth with its example sites-available/google-ldap-auth won't work.

It won't straight up fail, but there will be a cache miss every time.

cache_auth uses User-Password in the cache key. But because the password isn't in authorize, the cache config in authorize will perpetually check the cache with a blank password in the cache key.

[alandekok]

@andredigenova The documentation does not suggest that the password will be available in the authorize section when EAP-GTC is used.

The cache_auth_accept uses User-Password as the cache key, because it's caching PAP authentication, not EAP-GTC.