Re: [Emu] Proposal: SASL over EAP

Alan DeKok <aland@deployingradius.com> Fri, 17 April 2020 22:46 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 BB1123A08FD for <emu@ietfa.amsl.com>; Fri, 17 Apr 2020 15:46:48 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 5UvDoE-Rm97D for <emu@ietfa.amsl.com>; Fri, 17 Apr 2020 15:46:45 -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 9DE913A08F0 for <emu@ietf.org>; Fri, 17 Apr 2020 15:46:44 -0700 (PDT)
Received: from [192.168.46.130] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 260DF3AC; Fri, 17 Apr 2020 22:46:41 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <5E98981B.7020606@openfortress.nl>
Date: Fri, 17 Apr 2020 18:46:40 -0400
Cc: emu@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <260BBB7D-4201-4B68-92A4-6A2755555A2A@deployingradius.com>
References: <5E98981B.7020606@openfortress.nl>
To: Rick van Rein <rick@OPENFORTRESS.NL>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/9mKvGZ4mOp26cFs-i--4hxwyP_Y>
Subject: Re: [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: Fri, 17 Apr 2020 22:46:49 -0000

On Apr 16, 2020, at 1:38 PM, Rick van Rein <rick@OPENFORTRESS.NL> wrote:
> I think SASL over EAP would be useful.  Would it be in scope for EMU?

  I can't say if it's in scope.  But I don't think there's any other place this would would get done.  So it's a "maybe".

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

  Agreed.

> 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

  Interesting!

> 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.

  Or RADIUS....

  TBH, I can't recall seeing many WiFi deployments which use Diameter.  None of the access points support it. Similarly, EAP over LAN is implemented in most switches, but they definitely don't do Diameter.

  Is there a specific reason why Diameter was chosen?

>  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.

  I think that's a separate step from EAP, or SASL over EAP.  It may be difficult to in practice to define that tunneling.

> 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

  That draft looks reasonably clear.

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

  I have no opinions on that draft.

  Alan DeKok.