[strongSwan] Integrating strongSwan with a PAP-only RADIUS backend

[Kyle Seever]

Hello,

Thanks again for the timely response. I'm still not 100% clear on the way
these protocols interact so I made an attempt at diagramming it:

rightauth=eap-radius

------------   IKEv2   ------------   RADIUS  ---------
|  client  | -- EAP -- |  strong  | -- EAP -- |  AAA  |
------------           ------------           ---------

rightauth=eap-radius
rightauth2=xauth-radius

------------   IKEv2   ------------   RADIUS  ---------
|  client  | -- EAP -- |  strong  | -- EAP -- |  AAA  |
------------           ------------  <XAUTH>  ---------

If this is correct, then that definitely explains what I am seeing in my
packet captures.

Here is the situation I was hoping for, as the PAP RADIUS proxy won't
accept the forwarded EAP packets:

rightauth=eap-radius
rightauth2=xauth-radius

------------   IKEv2   ------------   RADIUS  ---------
|  client  | -- EAP -- |  strong  | --XAUTH-- |  AAA  |
------------           ------------           ---------

Is there any current plugin configuration that will let me accomplish
something like this, or will I have to downgrade my client's configuration
back to IKEv1?

Cheers,
-Kyle


On Fri, Dec 22, 2017 at 1:29 PM Noel Kuntze
<noel.kuntze+strongswan-users-ml at thermi.consulting> wrote:

> Hi,
>
> No.
> eap-radius encapsulates EAP packets in RADIUS packets.
> xauth-eap encapsulates the XAUTH conversation in an EAP conversation in
> RADIUS packets.
> They do not interact with each other beyond that they are implemented by
> the same plugin and use the same configuration files.
> The use of either method does not impact the other.
>
> Kind regards
>
> Noel
>
> On 22.12.2017 22:20, Kyle Seever wrote:
> > Hi Noel,
> >
> > Thanks for the quick response. To make sure I understand fully - without
> the /xauth-radius/ backend, /eap-radius/ simply encapsulates the EAP
> packets originating from the client within the RADIUS protocol back to the
> AAA. With /xauth-radius/, it sends XAuth credentials directly to the AAA
> via RADIUS (from the documentation: ".. to directly verify XAuth
> credentials using RADIUS User-Name and User-Password attributes.").
> >
> > That's where I picked up the 'translate EAP to XAuth' thought. What
> happens to the EAP encapsulation in this exchange? Are the XAuth
> credentials still nested within the EAP transfer?
> >
> > Thanks again,
> > -Kyle
> >
> > On Fri, Dec 22, 2017 at 12:52 PM Noel Kuntze
> <noel.kuntze+strongswan-users-ml at thermi.consulting> wrote:
> >
> >     Hi,
> >
> >     The xauth-radius authentication method encapsulates the XAUTH
> credentials in RADIUS packets. It does not translate an EAP conversation to
> XAUTH.
> >
> >     Kind regards
> >
> >     Noel
> >
> >
> >     On 22.12.2017 21:33, Kyle Seever wrote:
> >     > Hello,
> >     >
> >     > I am currently trying to integrate strongSwan (v5.3.5) with a
> PAP-only RADIUS proxy. Currently, I'm using a client profile of IKEv2 with
> EAP which connects to strongSwan without issue. strongSwan is configured
> with /rightauth=eap-radius/ and /rightauth2=xauth-radius:profile/. My
> reading of the eap-radius#xauth <
> https://wiki.strongswan.org/projects/strongswan/wiki/EAPRAdius#XAuth> plugin
> was such that it would translate the EAP conversation to regular XAuth
> credentials sent to the RADIUS backend via the regular User-Name and
> User-Password attributes. When I inspect the network traffic, the plugin is
> still encapsulating the EAP messages back to the AAA.
> >     >
> >     > What am I misunderstanding about the builtin XAuth backend in the
> plugin, and what are some options I have going forward? Will I have to
> downgrade to traditional XAuth over IKEv1?
> >     >
> >     > Thanks in advance,
> >     > -Kyle
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171223/6c83a4c8/attachment-0001.html>