[strongSwan] Different authentication methods
andreas.steffen at strongswan.org
Mon Apr 11 12:32:23 CEST 2016
authentication based on Windows Machine Certificates does
not use IKEv2 EAP but directly employs IKEv2 public key authentication
between VPN client and VPN gateway which very efficiently establishes
an IPsec tunnel with a mere 4 IKEv2 messages.
The Machine certificate must be installed in the "local machine"
section of the Windows registry. User Certificates installed in the
"current user" section of the registry as well as user smart cards
cannot be used.
IKEv2 EAP-TLS sets up a TLS session to an AAA server and is embedded
into the encrypted IKEv2 message stream between VPN client and
VPN gateway. Usually about 18 IKEv2 messages are needed to set up an
IPsec tunnel thus the protocol is rather verbose. The advantage is that
User Certificates installed in the "current user" section
of the Windows registry can be used as well as user smart cards.
The differentiation between Machine and User Certificates does apply
to Windows clients only. On a strongSwan client you can use efficient
IKEv2 public key authentication for any number of users.
On 11.04.2016 12:08, Fred wrote:
> hi all,
> These seem to be the industry norm for IKEv2:
> Machine certificates (is this no EAP??),
> Just wondering how the bottom two use cases differ?
> What kind of scenario would better suit Machine Certificates over
> EAP-TLS with client certificates? Both seem to use certificates for auth
> of client, but am I right that one uses EAP and the other not?
> Is one weaker than the other or are they comparable?
> Thanks! Just hoping to choose the correct method and hoping to
> understand the real world differences between the two.
> Users mailing list
> Users at lists.strongswan.org
Andreas Steffen andreas.steffen at strongswan.org
strongSwan - the Open Source VPN Solution! www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4275 bytes
Desc: S/MIME Cryptographic Signature
More information about the Users