Subject: [IPsec] Flexible multi-factor authentication

From: Wang Jian <[email-masked]>
Date: Mon, 26 Sep 2016 15:13:34 +0800

Hello,

When I researched for VPN solution for my company, IPsec was not an
option. Then IKEv2 was an option but yet met our requirements.

We chose from several SSL VPNs which also support ESP or UDP
transport. The key requirement IKEv2 doesn't meet is MFA functionality
and flexibility. Also, split dns functionality is missing.

The MFA we finally implemented is like

1. Users first authenticate themselves with username & password
2. according to the user's security group, another OTP authentication
step is needed or not. For users that OTP is needed, OTP
authentication is prompted or skipped if  (the device,the user) tuple
was authenticated recently (i.e. 24 hours)

* We could not get unique device id, so IP address and username are
used as the tuple. However we prefer to a generated permanent device
id by vpn client, the device's manufacturer-assigned id (or derived
hash if privacy is a concern), or time-limited http-cookie-like id
generated and returned by authenticator.

Our flexible 2FA authentication is implemented using RADIUS challenge.
The principles are

1. username & password authentication is used to integrated with
central user management. For ease of use, VPN client should be capable
of store password securely in device
2. authenticator controls the remaining authentication steps, and
decides which step should be done or be skipped.

Current IKEv2 doesn't provide an EAP authentication method to support
such flexible MFA use case. And in the new charter, there is no goal
of the kind.

IMHO, flexible MFA is most important for large scale enterprise
deployment. Please add it as a goal.

Regards,
Wang Jian

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 Sep 2016 13:35:29 +0300

Hi.

It seems that what you are looking for is a generic way to transport arbitrary strings from server to client and back again.

While not specifically intended for that, both EAP-GTC and EAP-OTP (types 6 and 5 respectively) have been (ab)used for that purpose. Not sure if that has happened in the context of IKEv2, though. GTC in a TTLS/PEAP/some other kind of tunneling has been done before, although when running EAP in IKE I don’t think you need yet another tunnel.  I guess it depends on the level of pre-existing trust that exists between the client and the VPN gateway (as opposed to the EAP authentication server).

Yoav

> On 26 Sep 2016, at 10:13 AM, Wang Jian <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Mon, 26 Sep 2016 14:49:51 -0400 (EDT)

On Mon, 26 Sep 2016, Wang Jian wrote:

> Also, split dns functionality is missing.

You could help by reviewing and telling us you are in favour of
working group adoption of:

https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02

> deployment. Please add it as a goal.

We dont really add goals that have no backers behind them. So if you
want this process to start, the best way would be:

1) write a draft and publish it to the list for feedback
    (maybe ask for co-authors to help)
2) ask for working group adoption
3) get the document ready as per working group consensus

Paul

---

From: Wang Jian <[email-masked]>
Date: Tue, 27 Sep 2016 16:48:54 +0800

Hi,

It's not only a generic way for authentication conversation, but also
a defined way for authentication conversation.

VPN clients, vpn servers and authentication servers must have a
standard, thus unified user experiences.

- What should be prompted to user during conversation, what should be
interpreted by clients, servers, and AS. Examples
* username and password authentication should be prompted to user if
no credential saved, but quitely handled if credential saved; when
username & password authentication fails, user is prompted to re-enter
* TOTP authentication request by server should be prompted to user, a
message and an input field, and client should not save the TOTP input
* Fingerprint authentication request by server should be prompted to
user and client should use fingerprint sensor (and handling timeout?)

- Input data type: although all input data can be stringified, how to
intepret them and how to handle them? TOTP number? human fingerprint?

- How to distinguish failure or unsupported method, for example
* fingerprint authentication is requested, but client replies that it
doesn't support it. Then alternative method such as TOTP can be used

Commercial SSL VPN vendors can ensure client, server and
authentication server to be in accordance. I think IKEv2 as a
standard, should also cover this area.

EAP-OTP and EAP-GTC in EAP-TTLS can be abused, but if they are not
abused the same way in clients, servers and authentication servers,
can't be used at all for enterprise deployment.

BTW: Can EAP-MD5/EAP-GTC/EAP-OTP be chained in EAP-TTLS in IKEv2? If
yes, any pointer to docs, examples?

Regards,
Wang Jian

---

From: Wang Jian <[email-masked]>
Date: Tue, 27 Sep 2016 17:08:30 +0800

> https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02

I am new here. I will try.

> 3) get the document ready as per working group consensus

I understand that. I will learn how to do these.

First I need some help and suggestion to identify what area should be
work on. For example, a new EAP type or generic EAP chaining
mechanism?

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 29 Sep 2016 14:05:12 +0300

> 1. Users first authenticate themselves with username & password

I.e., some suitable EAP method. 

> was authenticated recently (i.e. 24 hours)

And here again another suitable EAP method. 

> generated and returned by authenticator.

In normal case you use different IDs in different authentication
methods. I.e., you do device authentication first using Device ID as
your IDi, for that you can use certificates or something.

Then on the second phase you do user authentication using user name as
IDi and users password for EAP etc.

All this can be done using RFC4739 Multiple Authentication Exchanges
in the Internet Key Exchange (IKEv2) Protocol, which is there just for
this reason, i.e. to provide multiple authentication methods for one
connection. 

> such flexible MFA use case. And in the new charter, there is no goal

IKEv2 protocol with RFC4739 can support such methods, but
implementations might not implement them, so you need to find
implementation that actually support RFC4739 and uses it to do
multiple authentication methods in a way you want to use them. 

> deployment. Please add it as a goal.

This is exactly the reason why RFC4739 was done in 2006...
-- 
[email-masked]

---

From: Wang Jian <[email-masked]>
Date: Fri, 30 Sep 2016 02:06:15 +0800

> This is exactly the reason why RFC4739 was done in 2006...

Thanks for pointing me back at RFC4739. I came to know this RFC4739
when I evaluated strongswan.

I can't remember exactly why I put aside RFC4739. I re-read RFC4739 to
collect my memory.

""
It is assumed that both peers know what credentials they want to
present; there is no negotiation about, for instance, what type of
authentication is to be done.  As in IKEv2, EAP-based authentication
is always requested by the initiator (by omitting the AUTH payload).
""

The multiple authentication exchanges here are not flexible, especially for
mobile devices and BYOD scenario.

A flexible MFA mechanism should be server driven. The responder or AAA
backend can dictate what methods are mandatory, what methods are optional,
according to the knowledge the server collects. For example: username
and password is required, one of certificate, OTP or fingerprint is required.

Back to my company's setup, that is

1. Server mandates username and password authentication
2. If server has knowledge that this device of this user is
authenticated successful
    recently, server will skip the OTP authentication step, otherwise, OTP
    authentication is required if user is in a high priviledge user group

RFC4739 doesn't provide this flexibility. EAP-TTLS tunnelled authentications are
more attractive than RFC4739.

Regards,
Wang Jian