The issue is that PAP isn't an EAP type. PAP is an authentication type.
EAP-TTLS is the only widely used EAP type which can use a PAP inner, so I'm assuming you're using that.
When the server processes EAP-TTLS, it extracts the attributes inside EAP-TTLS' TLS tunnel and creates RADIUS attributes from them. It then 'proxies' a request containing these attributes (possibly merged with those from the RADIUS packet carrying EAP), and sends them to another virtual server (the default being 'inner-tunnel').
In order to perform PAP authentication in the inner tunnel, you need to set up PAP as you would for RADIUS.
etc/raddb/sites-available/inner-tunnel
server inner-tunnel {
authorize {
ldap | sql | files | whichever module you use to retrieve passwords
pap
}
authenticate {
pap
}
}
Note: You also need to select PAP as the inner method on the supplicant. There's no way to negotiate whether the supplicant uses an inner EAP method, or does PAP/CHAP/MSCHAPv2 using tunnel attributes. The supplicant sends attributes, the server goes along with whatever it sends. If the supplicant sends an EAP-Message attribute and the EAP module is configured, the server will do EAP. If the supplicant sends a User-Password attribute and the PAP module is configured the server will do PAP.
This is distinct from EAP, where the supplicant and server can negotiate the EAP method. There's a bunch of example exchanges in RFC5281 where you can see the different attributes being sent.
