All:
Here is a circumstance one could easily imagine, and in fact we attempted to
address in draft-lear-eap-teap-brski:
Client requires a new certificate for some reason or another. Perhaps its is
about to expire, or perhaps the signer has been compromised, or what have you.
We were thinking that we could use the Request-Action Frame for this purpose
with a type of PKCS#10. But that now seems wrong, as the language in the draft
states that one appends a Request-Action frame with a full TLV, and not just a
type, and further that the other end process the TLV. In looking at Jouni’s
code, he is doing precisely that with the PAC TLV.
And so it seems we have three choices:
Create a new TLV that has a length of two that can be used in a REQUEST_ACTION
frame.
Create a new TLV that is what we thought we meant: here is a list of
two(ish)-byte types whose TLVs I want you to send to me.
Hard code the ordering of requests so everyone knows what to expect.
Each of these has its own problems.
The first requires that we create a new EAP TYPE for TLV one end needs the
other to send, but it’s pretty easy to process. The second requires extra
processing but requires less standardization. The last seems to go against the
EAP model and reduces deployment flexibility.
Thoughts?
Eliot
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
