Return to Answer

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.

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.

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

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.

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.

server inner-tunnel {
    authorize {
        ldap | sql | files | whichever module you use to retrieve passwords

        pap
    }

    authenticate {
        pap
    }
}

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