[Emu] Identities and draft-ietf-emu-tls-eap-types-03

Alan DeKok <aland@deployingradius.com> Mon, 26 July 2021 11:45 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EC63A0D18 for <emu@ietfa.amsl.com>; Mon, 26 Jul 2021 04:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 6TOi9Uv1T078 for <emu@ietfa.amsl.com>; Mon, 26 Jul 2021 04:45:20 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B21C3A0D08 for <emu@ietf.org>; Mon, 26 Jul 2021 04:45:18 -0700 (PDT)
Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 6B523F8 for <emu@ietf.org>; Mon, 26 Jul 2021 11:45:16 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
From: Alan DeKok <aland@deployingradius.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Message-Id: <502A7B31-1177-477D-B177-D415BAF67E61@deployingradius.com>
Date: Mon, 26 Jul 2021 07:45:14 -0400
To: EMU WG <emu@ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/1DQ0Z0Bb3YyOqBcHBs2QNZ-unFc>
Subject: [Emu] Identities and draft-ietf-emu-tls-eap-types-03
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jul 2021 11:45:23 -0000

  I propose to add a new section which discusses identities.

  As background, an (un-named) vendor recently made changes to their EAP stack.  The configuration for TTLS/PEAP now takes the external (anonymous) identity, and uses that as the inner identity.

  i.e. instead of sending "@example.com" for the outer identity, and "myname" for the inner one, it just sends "@example.com" for both.

  Perhaps unsurprisingly, this causes authentication to fail.  The work-around is to reconfigure the supplicant so that the outer identity is the "real" one.  This has privacy implications, as the inner identity is now being exposed.

  I'm proposing new text which explains some basic ideas about identities, and what should/should not be done.  I don't think that these proposals are controversial, but they are perhaps surprising to some implementors.



Identities
------------

[EAPTLS] Sections 2.1.3 and 2.1.7 recommend the use of anonymous NAIs
[RFC7542] in the EAP Identity Response packet.  However, as EAP-TLS
does not send application data inside of the TLS tunnel, that
specification does not address the subject of "inner" identities in
tunneled EAP methods.  This subject, however, must be addressed for
the tunneled methods.

Using an anonymous NAI has two benefits. First, an anonymous identity
makes it more difficult to track users.  Second, an NAI allows the EAP
session to be routed in an AAA framework.

For the purposes of tunneled EAP methods, we can therefore view the
outer TLS layer as being mainly a secure transport layer.  That
transport layer is responsible for getting the actual (inner)
authentication credentials securely from the EAP peer to the EAP
server.  As the outer identity is simply an anonymous routing
identifier, there is little reason for it to be the same as the inner
identity.  We therefore have a few recommendations on the inner
identity, and its relationship to the outer identity.

For the purpose of this section, we define the inner identity as the
identification information carried inside of the tls tunnel.  For
PEAP, that identity may be an EAP Response Identity.  For TTLS, it may
be the User-Name attribute.

Implementations MUST not use anonymous identities for the inner
identity.  If anonymous network access is desired, eap peers MUST use
EAP-TLS without peer authentication, as per [EAPTLS] section 2.1.5.
EAP servers MUST cause authentication to fail if an EAP peer uses an
anonymous identity.

Implementations SHOULD NOT use inner identies which contain an NAI
realm.  The outer identity contains an NAI realm, which ensures that
the inner authentication method is routed to the correct destination.
As such, any NAI realm in the inner identity is redundant and
unnecessary.

However, if the inner identity does contain an NAI realm, that realm
MUST be identical to the outer identity NAI realm.  There is no reason
for these realms to be anything other than bit-for-bit identical.