Dan Harkins wrote: > Is it the intention of the community that each individual EAP method > will have to define ciphers to negotiate, how to negotiate a cipher, > how to get a key for the cipher, how to use the cipher to protect a new > payload that contains arbitrary TLVs? I personally think that's a bad > idea. Each EAP method would have to basically duplicate a whole bunch > of capabilities.
I agree that it's a bad idea. Where additional data needs to be transferred, it would be best to have a way that is EAP method agnostic. > Would it not be better to do this with two new EAP codes to pass TLVs > in each direction and the have a single definition of the cipher and a > single definition of how to get the key and a single definition of how > to use the cipher and key to protect packets with these new EAP codes? > That leaves EAP methods to do authentication and generation of the MSK > and EMSK, period. The (optional) exchange of packets with these new EAP > codes would happen after the EAP method has finished sending requests > and responses and before "success" is declared. There are multiple ways of doing this. That is one approach. > Disregarding the EMU charter for a minute, would this be a better > architectural solution? Yes. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
