Subject: [Emu] Proposal: SASL over EAP

From: Rick van Rein <[email-masked]>
Date: Thu, 16 Apr 2020 19:38:35 +0200

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

---

From: Alan DeKok <[email-masked]>
Date: Fri, 17 Apr 2020 18:46:40 -0400

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

> networks.  However, with VPNs these uses get mixed.

  Agreed.

> - A SASL mech "SXOVER" to support authentication of foreign realms

  Interesting!

> 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

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

> https://www.ietf.org/archive/id/draft-vanrein-eap-sasl-00.txt

  That draft looks reasonably clear.

> https://tools.ietf.org/html/draft-vanrein-diameter-sasl-03

  I have no opinions on that draft.

  Alan DeKok.

---

From: Rick van Rein <[email-masked]>
Date: Sat, 18 Apr 2020 20:05:25 +0200

Hi Alan,

>> the Internet, and receiving back tunnel information.

That's what everyone is thinking ;-)

The reason for Diameter is that it scales up to the Internet (in terms
of connection pooling / efficiency and in terms of security).  RADIUS is
really useful for internal networks, but becomes rather clumsy when
crossing the Internet -- it is not suited for worldwide public service.

>   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 D…

Catch-22 -- no use case, no software.  That's why I'm describing the use
case here.  We'll probably package our kit for OpenWRT, so everyone can
benefit / derive from it.

A patchy solution is possible for closed routers; RADIUS and Diameter
can crossover, so a local node doing that is possible.

>   Is there a specific reason why Diameter was chosen?

Certainly,

 - It enforces mutually authenticated TLS for peer-validation
 - It does not silently assume a profile but negotiates at startup
 - It can pool validated TLS connections for reuse
 - It runs over SCTP for realiability without head-of-line blocing

These are hardly a concern for internal networking, and very much
concerns for dynamic realm crossover.

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

Yes it is separate, and just here to give you some context.  There are
several AVP sets for tunneling in RADIUS / Diameter, and making a choice
would probably help the crossover to work in general.

>   That draft looks reasonably clear.

Thanks for taking the time to judge that.

I'll wait a little more to hear others respond on what to do here.  I
agree with your take that it's not an exact fit here but that it has no
other place either.

>   I have no opinions on that draft.

...as it merely provides context, yes of course.

Thanks,
 -Rick

---

From: Alan DeKok <[email-masked]>
Date: Sat, 18 Apr 2020 14:47:30 -0400

> crossing the Internet -- it is not suited for worldwide public service.

  Uh.... what?

  RADIUS is used in Eduroam, which is a worldwide public service.  There are many other roaming groups using RADIUS.

  It seems to be fine.  I'm not sure why you think otherwise.

> case here.

  That is definitely *not* the reason people avoided Diameter.

  The reason is simple: RADIUS does everything that the enterprises and ISPS need.  Even Telcos use RADIUS for many things.

  Diameter won in the Telco space because (at a high level) it was mandated in the 3G standards.  And even it seems to be dropped in 5G, in favour of JSON over QUIC.

  So your starting assumptions are wrong, which makes it easier for your conclusions to end up in the wrong place.

> can crossover, so a local node doing that is possible.

  The Diameter protocol is about 100x more complex than RADIUS.  It will take *years* before router vendors release inter-operable Diameter clients.  Their best bet is to just do RADIUS, and rely on a Diameter server in order to do RADIUS to Diameter translation.

  There is just too little benefit for vendors to implement this in their client products.

> - It enforces mutually authenticated TLS for peer-validation

  There is a RADIUS over TLS transport, which is widely implemented and deployed.  There's also dynamic peer discovery.  Less widely implemented, but definitely used.

> - It does not silently assume a profile but negotiates at startup

  A profile for... what?

> - It can pool validated TLS connections for reuse

  RADIUS implementations already do this.  Source code is available.

> - It runs over SCTP for realiability without head-of-line blocing

  It *theoretically* runs over SCTP.  In practice, SCTP is not widely used.

> would probably help the crossover to work in general.

  In RADIUS, those attributes provide for VLAN assignment.  They don't provide for secure tunnels to "home" networks.

  Diameter may be different, as I haven't looked at in detail.

  The short summary is that if you want this to be widely used in the short term, you should define a RADIUS transport. 

  While freeDiameter exists, it doesn't seem to have an active mailing list.  It's policy capability appears small.  It seems to be mainly a proxy.  Which means that you are limiting the market for this idea to people who are willing to pay $100K+ for a commercial Diameter product.

  Such a strong limitation means that this idea is likely to be dead in the water even before it starts.  I would therefore suggest expanding the use-case for this proposal.

  Alan DeKok.

---

From: Rick van Rein <[email-masked]>
Date: Sat, 18 Apr 2020 21:55:20 +0200

Hi,

This is turning into a discussion about RADIUS versus Diameter.  Please
note that this is not implied by my proposal of SASL over EAP; that I
merely want to be somewhat clear about how the use case could look.

I do thank you for evaluating these details, and am aware that the
anticipated advantages of Diameter have balancing arguments.

Thanks,
 -Rick

---

From: Alan DeKok <[email-masked]>
Date: Sat, 18 Apr 2020 18:27:12 -0400

On Apr 18, 2020, at 3:55 PM, Rick van Rein <[email-masked]> wrote:
> This is turning into a discussion about RADIUS versus Diameter.

  I'm suggesting that since EAP runs over AAA protocols, it helps to understand where each AAA protocol is used, and why.

  The alternative is to have a solution which isn't applicable to existing problems.

  If your proposal is intended to run mainly in the 3G space, then my previous message explains which protocol you use, and why.  If your proposal is intended to run mainly in the enterprise / ISP space, then my previous message also explains which protocol you use, and why. 

  I believe that the document is clear enough so that someone can implement it.  Which is appreciated, as many protocol drafts are maddeningly obtuse.

  The concern is that the document does not explain *who* would use this solution, or *why* they would use it.  Or, why it would be used instead of existing EAP methods.

  On another technical note, page 3 says:

   What SASL stands to gain
   is the ability to be carried over widely used AAA backend protocols
   such as RADIUS and Diameter.  When a site is standardising its
   authentication on SASL, it is possible for both network access and
   end-user applications to isolate authentication sequences and relay
   them to a shared AAA backend.  This facilitates centralised
   management of identities and credentials.

  The ABFAB working group standardized precisely this many years ago.  One implementation is Moonshot:

https://www.jisc.ac.uk/rd/projects/moonshot

  They demonstrated roaming users authenticating to home networks using EAP over AAA.  Not just for network access, but for SSH, Web login, etc.  It would be good to explain why ABFAB is not applicable to this problem.

  I'll speak further from personal experience in this area.  I've worked with roaming groups and companies for a long time.  Typical commercial roaming integrations take many months.  The technical side (e.g. dynamic roaming lookups && certificate exchanges) is the most trivial part of it.  Also, these integrations are largely for ISPs and Telcos.  But not for enterprises.

   My experience has been that most enterprises are been unwilling to discuss roaming.  They see no benefit in setting up or using AAA servers so that employees can roam.

   So... what is the motivation for this proposal?  Who will use it?  Why?

  Alan DeKok.

---

From: Rick van Rein <[email-masked]>
Date: Wed, 22 Apr 2020 09:51:38 +0200

Hi Alan / EMU,

I'll try to talk to Paul @ SURF about Diameter <--> RADIUS; he runs
Eduroam and I think he has mentioned Diameter before.  Our use case is
completely new anyway, so we have a free choice.

Good to hear that EAP-SASL sounds implementable.  We haven't built it,
but I usually "mentally program" the stuff while spec'ing.

>   The concern is that the document does not explain *who* would use this solution, or *why* they would use it.  Or, why it would be used instead of existing EAP methods.

I can add that, thanks for asking.  There are WG's where I've been
requested to remove such contextual aspects.

> https://www.jisc.ac.uk/rd/projects/moonshot

I know about Moonshot, and that the project was abandoned.  What it does
iss the reverse; Moonshot runs EAP on top of GSS-API / SASL, whereas I
am proposing SASL on top of EAP.

>   They demonstrated roaming users authenticating to home networks using EAP over AAA.  Not just for network access, but for SSH, Web login, etc.  It would be good to explain why ABFAB is not applic…

That is fair crisicism, and I will think it over for a new version.

Thanks for the input, they are good input to a new version.  I'll think
about a few for a while, as that usually helps to better balance things.

-Rick

---

From: Jim Schaad <[email-masked]>
Date: Wed, 22 Apr 2020 11:56:38 -0700

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Rick van Rein
Sent: Wednesday, April 22, 2020 12:52 AM
To: Alan DeKok <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] Proposal: SASL over EAP

Hi Alan / EMU,

I'll try to talk to Paul @ SURF about Diameter <--> RADIUS; he runs Eduroam
and I think he has mentioned Diameter before.  Our use case is completely
new anyway, so we have a free choice.

Good to hear that EAP-SASL sounds implementable.  We haven't built it, but I
usually "mentally program" the stuff while spec'ing.

>   The concern is that the document does not explain *who* would use this
solution, or *why* they would use it.  Or, why it would be used instead of
existing EAP methods.

I can add that, thanks for asking.  There are WG's where I've been requested
to remove such contextual aspects.

> https://www.jisc.ac.uk/rd/projects/moonshot

I know about Moonshot, and that the project was abandoned.  What it does iss
the reverse; Moonshot runs EAP on top of GSS-API / SASL, whereas I am
proposing SASL on top of EAP.

[JLS] I am a bit surprised at hearing this is abandoned given that they
released an update of the software on the 20th of April

>   They demonstrated roaming users authenticating to home networks using
EAP over AAA.  Not just for network access, but for SSH, Web login, etc.  It
would be good to explain why ABFAB is not applicable to this problem.

-Rick

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: Rick van Rein <[email-masked]>
Date: Wed, 22 Apr 2020 21:37:32 +0200

Jim,

> released an update of the software on the 20th of April

I heard about stopping Moonshot years ago; this is newer info.

-Rick