On Apr 16, 2020, at 1:38 PM, Rick van Rein <r...@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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
