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 haveThere 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 b) requires a secure relationship between Authenticator and Radius Server. (a radius secret, and an entry in the Radius Server's client table) 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. (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. 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. 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 =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
