TNC Fragmentation ACKs [diff included]

[Arne Welzel]

Hi all,
second try...

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 [1] says that the TNC fragmentation is based on
that of other TLS methods.

In the EAP-TLS RFC [2] 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
 acknowledgement.
 ...

Additionally in the EAP-TTLS RFC [3] 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
Version.
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.

Sources:
[1]
http://www.trustedcomputinggroup.org/resources/tnc_ift_protocol_bindings_for_tunneled_eap_methods_specification
[2] http://www.faqs.org/rfcs/rfc2716.html
[3] http://tools.ietf.org/html/rfc5281

Any comments welcome,
Arne


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tnc_fragmentation.diff
Url: http://lists.shmoo.com/pipermail/hostap/attachments/20100209/fdeed325/attachment.txt