IETF Logo Mail Archive

[Emu] Proposal: SASL over EAP

Rick van Rein <rick@openfortress.nl> Thu, 16 April 2020 17:38 UTC

Return-Path: <rick@openfortress.nl>
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 B6B453A0898 for <emu@ietfa.amsl.com>; Thu, 16 Apr 2020 10:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=openfortress.nl
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 pzG2-4mhi7I9 for <emu@ietfa.amsl.com>; Thu, 16 Apr 2020 10:38:44 -0700 (PDT)
Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D9C3A0891 for <emu@ietf.org>; Thu, 16 Apr 2020 10:38:44 -0700 (PDT)
Received: from popmini.vanrein.org ([IPv6:2001:980:93a5:1::7]) by smtp-cloud8.xs4all.net with ESMTP id P8THj2dwxlKa1P8TIjV6Lj; Thu, 16 Apr 2020 19:38:42 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=openfortress.nl; i=rick@openfortress.nl; q=dns/txt; s=fame; t=1587058719; h=message-id : date : from : mime-version : to : subject : content-type : content-transfer-encoding : date : from : subject; bh=Pn/QXscMBwshxN2WnGSTDAXreNcG1Ul99EEM61Ma990=; b=G8HgJuUhbKUnADuxekobRn9B2U/DRnpjM96fMEgaTAwMdd6Mx/b1dZer iK32gDYbLkILFBIZOc9r57V0pdeQ0xCSyvNJx6Hp06kH4iwNL3k052L719 2CF+ciEKmn7W8RMi5+Z7rJsz/AGn9RHnB4sCMvYa/a2gfGKT0Cl+YY8fs=
Received: by fame.vanrein.org (Postfix, from userid 1006) id A892B37B05; Thu, 16 Apr 2020 17:38:39 +0000 (UTC)
X-Original-To: emu@ietf.org
Received: from airhead.local (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTPA id 6990A143; Thu, 16 Apr 2020 17:38:36 +0000 (UTC)
Message-ID: <5E98981B.7020606@openfortress.nl>
Date: Thu, 16 Apr 2020 19:38:35 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: emu@ietf.org
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bogosity: Unsure, tests=bogofilter, spamicity=0.520000, version=1.2.4
X-CMAE-Envelope: MS4wfGGqy9jfPrLCbqZbnwN5EP7ciqaOekVgZyemW4viYz+3Xe9UQueExbuDiDxggw872DCbTwSUvGP7yYo//6BHSu31gIaOqTkdKpqOxVBEOYg9bn1MsUur tgoszLLPSZ/QPaHf0uTx+d3TmDChJAwteebKz2n1kXSMac+yzCorTJckRudQPNyv3h/7dBkfvtw6NQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/7dvsBfVnhBGqWV4BpmImSznZXBo>
Subject: [Emu] Proposal: SASL over EAP
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: Thu, 16 Apr 2020 17:38:50 -0000

Hello,

I think SASL over EAP would be useful.  Would it be in scope for EMU?

SASL is normally used for applications, while EAP authenticates
networks.  However, with VPNs these uses get mixed.

We're making a few other changes to SASL that line up with this:
 - Diameter embedding of SASL tokens
 - A SASL mech "SXOVER" to support authentication of foreign realms

An interesting usecase for EAP-SASL with all this would be WiFi and LAN
authentication (EAPOL or 802.1x) passed over Diameter to *any* domain on
the Internet, and receiving back tunnel information.  Clients would be
tunneled to their own network/IP/routing and it would be easier for
public access providers to offer full networking without worry about the
behaviour it outputs over their IP range.

This may in fact be a path for your purpose of out-of-band based
authentication; SASL mechanisms could use such extensions too and SXOVER
might help to protect the general mechanism.


Before this group existed I wrote a spec for EAP-SASL, is it worthwhile
to continue, and how/what do you advise?
https://www.ietf.org/archive/id/draft-vanrein-eap-sasl-00.txt

The other work is progressing in
https://tools.ietf.org/html/draft-vanrein-diameter-sasl-03


Looking forward to the EMU opinions,


Kind regards,

Rick van Rein
InternetWide.org

v2.23.0 | Report a Bug | By Email