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.
>>>>
>
signature.asc
Description: OpenPGP digital signature
