[strongSwan] EAP lowest common denominator

[Noel Kuntze]

Hello Volodymyr,

Yes, but the following thought is not.
Windows, for example, requires pubkey auth by the responder, but then only authenticates itself (initiator) against the responder using eap-tls.
So in eap-tls with Windows, the responder doesn't authenticate itself against the initiator in eap-tls, but in pubkey auth beforehand.
Nonetheless, you need certificates either way.

What is your problem with certificates? Are you trying to build the 10.000th VPN service?

Kind regards

Noel

On 02.03.2018 19:07, Volodymyr Litovka wrote:
> Hello Noel,
> 
> unfortunately, EAP-TLS require certificates on both sides, which I strongly need to avoid. Am I wrong?
> 
> On 3/2/18 5:37 PM, Noel Kuntze wrote:
>> Hello Volodymyr,
>>
>> EAP-TLS seems to be widely supported as well. If the responder authenticates itself first, the succeeding EAP exchange is encrypted and authenticated.
>>
>> Kind regards
>>
>> Noel
>>
>> On 02.03.2018 13:46, Volodymyr Litovka wrote:
>>> For example, it seems that MacOS (10.12 Sierra) native client supports only EAP-MSCHAPv2 and rejects any other methods, e.g.
>>>
>>> when I configure swanctl.conf in the following way:
>>>
>>> connections {
>>>      ikev2-userpass {
>>>        [ ... ]
>>>        remote-1 {
>>>            auth = eap-peap
>>>            # auth = eap-ttls
>>>          }
>>>        }
>>>   }
>>>
>>> I get the following messages in logs:
>>>
>>> Mar  2 14:23:32 vpn strongswan: 16[ENC] <ikev2-userpass|4> generating IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/PEAP ]
>>> [ ... ]
>>> Mar  2 14:23:32 vpn strongswan: 11[ENC] <ikev2-userpass|4> parsed IKE_AUTH request 2 [ EAP/RES/NAK ]
>>> Mar  2 14:23:32 vpn strongswan: 11[IKE] <ikev2-userpass|4> received EAP_NAK, sending EAP_FAILURE
>>>
>>> and same for EAP-TTLS: "generating IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/TTLS ]"receive EAP/RES/NAK
>>>
>>> So the question is there an alternative to EAP-MSCHAPv2 which can be used on mostly deployed clients?
>>>
>>> On 3/2/18 10:48 AM, Volodymyr Litovka wrote:
>>>> Hi colleagues,
>>>>
>>>> which, from your experience, is the lowest common denominator for EAP methods availability on various clients (hardware appliances [Cisco, Juniper, Mikrotik, etc], software clients [Windows, MacOS, iOS]), if we don't talk about EAP-MSCHAPv2 ?
>>>>
>>>> Since mschap use NTLM hash which isn't secure enough, it's not bad to store credentials in backend in a non-reversable format like SHA2. Looking at the following table - http://deployingradius.com/documents/protocols/compatibility.html - I see two possible ways to achieve this target: EAP-GTC or PAP, tunneled inside other EAP method (TTLS, PEAP, other which require only server certificate).
>>>>
>>>> So the question is - which pair of inner/outer EAP methods you will recommend to choose in order to get support for most client types and to have ability to store credentials in backend in non-reversable hash form?
>>>>
>>>> Thank you.
>>>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180303/8b3708b1/attachment.sig>