[IPsec] Flexible multi-factor authentication

Wang Jian <larkwang@gmail.com> Mon, 26 September 2016 07:13 UTC

Return-Path: <larkwang@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC2212B04F for <ipsec@ietfa.amsl.com>; Mon, 26 Sep 2016 00:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF5_3Y-yu_NX for <ipsec@ietfa.amsl.com>; Mon, 26 Sep 2016 00:13:35 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7AF12B036 for <ipsec@ietf.org>; Mon, 26 Sep 2016 00:13:35 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id 192so42382185vkl.2 for <ipsec@ietf.org>; Mon, 26 Sep 2016 00:13:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=WkKbNTpNLcfTO2lGtiBrltFmXF/Im/8pPug4og5HPMM=; b=TX06SaOfy5jPMqlu+DjuYINKgna/Rpa2kfYon3jCN4KVhPYYc6n0RcgXqI2RcpLKJU FU2KCAdzv7soqKU+K9+YWDoiWt6+tPupLXURytbOnZyO9EojqUeHKd03pvleJs5X1Gd/ k026AG0W2bH+cMVS5BDvdLL2fAoz0zaWXTN4sP7YzgRamL4TEZGNkE0ox/qRocdKUoaB mw7o4ONHrWh1O6KrKTwkrhWP2/aD7Jxmlwlxb83ghKRQEifJ/EeX9+de0OQAbIglkIre GJQPWmAf1Cj0hD0rek8accd36sTZQZWwgzxlYrCxjSmGs4dh8a/eXfWk4IP8SIjsYHbE iOCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WkKbNTpNLcfTO2lGtiBrltFmXF/Im/8pPug4og5HPMM=; b=Pd168AforQLeEij9PGrDWMg+qIGDnTU2x4tE9XO8OI+THLjBFJYXVLaAugHLgUWMvl usOXWgx0ysGZxBYM3LN/+lxO6UZq7JLF7W7cIi8OJZ/2TPqC94Teo2XtZLX+YSxYiWyS AJi69LjhTsxZqv4mzqIsgmt+Pgw4nXOr5HNaD0+RaGegeqlVkU5nsvDDtiMtKsdasR7P IhWWsot18CuCsQucRinplhZBhQKpOzPH9scZdqq/oAEZJV4TsZDzc1G1MG0UX3OyiBhG KRvmRg/zvok0YQxNxiU2lBrC6+Fg3x6qg3zJ23JJh2mps35zvz4ABVHq61oI6ls6BYS2 b3Gw==
X-Gm-Message-State: AA6/9RnfwtrrImK1MozEIdAySoMy2u87rnR2JRn01JLc2qT8y/SKPr7QRNB0+VKfkgwStkA+7iGKy2xEmN4IAw==
X-Received: by 10.31.11.1 with SMTP id 1mr7108753vkl.118.1474874014653; Mon, 26 Sep 2016 00:13:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.150.132 with HTTP; Mon, 26 Sep 2016 00:13:34 -0700 (PDT)
From: Wang Jian <larkwang@gmail.com>
Date: Mon, 26 Sep 2016 15:13:34 +0800
Message-ID: <CAF75rJA5Y9dW7xU91BZ-OFOxB_+M8w50_ySN4knOh-Cv-BLxtA@mail.gmail.com>
To: IPsecME <ipsec@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/6ClgEMIWc29bWnUM3Gdff4pyOIU>
Subject: [IPsec] Flexible multi-factor authentication
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2016 07:13:37 -0000

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