Re: [Stackevo] draft-thomson-use-it-or-lose-it

[Eliot Lear <[e-mail]>]

Hi Martin,

I'm just delving into Radius and EAP, but what I like is how opacity was
used early on for privacy purposes.   So for instance, perhaps the
largest federated network in the world is Eduroam, and it is built on
Radius and EAP.  Proper layering has made it possible for there to be
inner and outer identities that allow for IdPs to manage their user
bases independently and to keep some amount of privacy.  Klaas Wierenga
at GEANT was the principal designer.

We are trying to expand out AAA for IoT use cases, and in that context. 
Some of that work was done with EAP-TEAP, but a little bit more is
needed.  A key insight there is that it is sort of in between routing
and application, in that it is multi-party, but not to the insane extent
of a routing system.

At the Internet layer, of course, we have a big fat wasteland called
240/4, which is just sad.  Vince Fuller, Dave Meyer, and I wanted to
free up that space, but there were serious concerns that using it would
cause harm to systems not expecting it to be used, or simply would be
ineffective.  That was a while ago.

Eliot


On 07.08.18 02:24, Martin Thomson wrote:
> On Mon, Aug 6, 2018 at 11:22 PM Eliot Lear <[e-mail]> wrote:
>> In short, my suggestion is to first decide on what applicability you
>> want to have, and if broad, then let's explore some other cases.
> Brian made a similar comment.  I would really like to hear more about
> broader experience with this.  It seems like TLS is uniquely crappy
> when it comes to these issues (investigating why would be another
> valuable research subject...), but I can't believe for a moment that
> the implementation ecosystem of other protocols is pristine and
> blemish-free.
>
> If your experience with the AAA protocols reveals anything, I'd be
> very interested.  My understanding of RADIUS, having used it many
> years ago, was that it was a great example of the active use thing I
> advocate for.  That is, the mechanism you use to extend the protocol
> is so fundamental to the protocol that you cannot avoid correctness in
> extension handling.  Even having a stronger reaffirmation of that
> would be helpful.
>