TNC Fragmentation ACKs [diff included]
Tue Feb 9 06:11:36 PST 2010
I've got a question regarding TNC fragmentation in wpa_supplicant.
wpa_supplicant expects a ACK to have a payload of 0.
Line 77, 231 and 264 in src/eap_peer/eap_tnc.c indicate this.
The IF-T specification  says that the TNC fragmentation is based on
that of other TLS methods.
In the EAP-TLS RFC  the meaning of the flags field is described and
there is one paragraph which says:
The S (EAP-TLS start) is set in an EAP-TLS Start message. This
differentiates the EAP-TLS Start message from a fragment
Additionally in the EAP-TTLS RFC  states:
An Acknowledgement packet is an EAP-TTLS packet with no additional
data beyond the Flags octet, and with the L, M, and S bits of the
Flags octet set to 0. (Note, however, that the V field MUST still be
set to the appropriate version number.)
So it seems to me that even in a TNC ACK the flags should be present.
Leading to a payload of 1. Furthermore those flags contain the TNC
Appended is a git diff output of the modified length checks and ACK
generation in src/eap_peer/eap_tnc.c .
I've found this issue while testing a IMC/IMV pair which requires
fragmentation. The tncs at fhh implementation sends ACKs with the flags
field / version field set. wpa_supplicant expects it to be completly empty.
If the assumptions about the flags field are incorrect, i would be glad
if someone would enlighten me how to interpret it.
Any comments welcome,
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the Hostap