Hi Michael: Just a clarification. If you are referring to IEEE 802.1X with 1x , then I have to say that IEEE 802.1X is not EAP but it is using EAP. More specifically, IEEE 802.1X is an EAP lower-layer. More comments inline.
> El 16 ago 2016, a las 15:27, Michael Richardson <mcr+i...@sandelman.ca> > escribió: > > > Toerless Eckert <eck...@cisco.com> wrote: >> 1. We did earlier in Anima investigate if/how we could/should use EAP >> to perform ANIMA bootstrap. It turned out that transporting all the >> desired key-infrastructure bootstrap messages across EAP would have > > There are two other key issues with the 1x-architecture of supplicants, > authenticators and authorization servers (AS). > > The architecture usually looks like: (nice picture at: > https://en.wikipedia.org/wiki/IEEE_802.1X ) > > S<--EAP-TLS over EAP over 1x/PANA->Authenticator<--EAP-over-radius-->AS > > The problem with this architecture is that it: > a) always creates state on the authenticator [Rafa] How do you perform an authentication exchange otherwise? Unless you are thinking something like Kerberos where the KDC is stateless. > > b) requires a secure relationship between Authenticator and Radius Server. > (a radius secret, and an entry in the Radius Server's client table) [Rafa] I think we should talk about AAA server in general because other protocols as Diameter can be used. Moreover the authenticator has to have a secure relationship with the next hop AAA server (AAA proxy) not with the (home) AAA server. Hence, the scalability. > > c) And we'd then have to run EST over the EAP/TLS connection, and do it > not with the radius server, but with the Registar. [Rafa] That is why I mentioned that, perhaps, the assistance of the EAP lower-layer (e.g. CoAP) could help with this task. > > (a) is a cost to absorb. > (b) could be mitigated by changing the Authenticator to really be: > > Authenticator . o O ( <Proxy>-----EAP-over-GRASP---<Registar> ) > > and having no radius server at all. [Rafa] That is called in EAP: EAP Stand-Alone authenticator. > Of course, having got rid of that > compoennt, the commonality with the various 1x infrastructures is really > non-existant. All we've done is introduce EAP fragmentation (and code paths) > in a place where it will get used only once. > > Instead, a good way to think about ANIMA bootstrap is that it's the way in > which you get credentials which you can *then* use for 1x, if that's what > your infrastructure wants. > Today, those credentials are distributed > out-of-band. [Rafa] Precisely this is the kind of separation we are proposing in our work for IoT bootstrapping. Best Regards. > Seperating bootstrap from the 1x process not only simplifies > the bootstrap process, but it also simplifies the 1x code base, as it doesn't > have to figure out if the new pledge is trying to join the network, or trying > to bootstrap. > > (I'm reminded of the Robert Frost poem about The Road Not Taken. Often > it is thought to be about taking chances in life. I tend to think that > when it comes to security, that it's best not have divergent paths in code, > unless both have regularly used test cases: "I doubted if I should ever come > back") > > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: r...@um.es ------------------------------------------------------- _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
