On Mon, 2 Jan 2023, at 20:15, Alan DeKok wrote:
>> Appendix C.6 (Sequence of EAP Methods) will need to be updated to show this
>> too.
>
> The text has this, which seems sufficient:
>
> <- EAP-Request/
> EAP-Type=TEAP, V=1
> (TLS change_cipher_spec,
> TLS finished,
> Identity-Type TLV,
> EAP-Payload-TLV[
> EAP-Request/Identity])
It shows it for the *first* method but not subsequent methods.
For later methods it shows:
<- Intermediate Result TLV (Success),
Crypto-Binding TLV (Request),
Identity-Type TLV,
EAP Payload TLV [EAP-Type=Y],
// Next EAP conversation started after successful completion
of previous method X. The Intermediate-Result and Crypto-
Binding TLVs are sent in next packet to minimize round
trips. In this example, an identity request is not sent
before negotiating EAP-Type=Y.
// Compound MAC calculated using keys generated from
EAP method X and the TLS tunnel.
Intermediate Result TLV (Success),
Crypto-Binding TLV (Response),
EAP-Payload-TLV [EAP-Type=Y] ->
Here we have it tell us the opposite:
"In this example, an identity request is *not* sent before negotiating
EAP-Type=Y"
When when I tried talking to Windows doing this the result was a stall and a no
longer responsive supplicant
I can go back and dig into this more to see if my conclusion was right (ie.
must send EAP-Identity for every method in sequence) if that helps?
Thanks
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
