Rafa Marin Lopez <[email protected]> wrote: > that may sound like an insurmountable obstacle. However, for example, > EAP-AKA implies three messages, two related with EAP-AKA and the final > EAP Success which is four byte length. EAP Req/id and Resp/id is not
EAP-AKA is nice because it provides authentication of the network to the device. In the context of a vendor (manufacturer) which sells devices (with the same SKU, same firmware, same set of trust roots) to different operators, I think that a complete EAP transaction back to the manufacturer would be required to authorize things. EAP-AKA being based upon shared-secrets installed at manufacturer time (in the mobile phone case, it's just the "SIM" card, but I assume it's just built-in AKA functionality, not a physical SIM), the manufacturer has no asymmetric mechanism to delegate authorization through a supply chain, and so has to do it online. I'm not complaining about doing it online: I just want to be sure that we all understand the shape of this solution. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
