TNC Fragmentation ACKs [diff included]

[Jouni Malinen]

On Tue, Feb 09, 2010 at 03:11:36PM +0100, Arne Welzel wrote:

> The IF-T specification [1] says that the TNC fragmentation is based on
> that of other TLS methods.

It does point to TLS-based protocols, but for me that is more of an
informational note than any kind of normative reference that would
require the rules of some not clearly specified protocol definition
would need to be followed.

> 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.

This is one interpretation, but I would not put much value for what is
defined for EAP-{TLS,TTLS,PEAP,FAST} in this context. As far as EAP-TNC
is concerned, the normative description of the acknowledgement packet is
in TNC IF-T section 6.1.2: "acknowledgement packet -- an EAP-TNC packet
with no data". Unfortunately, "with no data" can be interpreted in
multiple ways. The current implementation in wpa_supplicant seems to be
based on interpretation that this means there is no payload whatsoever
after the EAP header and the Type field. The interpretation you describe
is saying that there is no Data Length or Data fields, but the
Flags|Ver field is included.

> Appended is a git diff output of the modified length checks and ACK
> generation in src/eap_peer/eap_tnc.c .

I'm open to adding the Flags|Ver octet into the fragment ack frames.
However, I do not think it would be a good idea to enforce this on the
receive side taken into account that this may result in interoperability
problems that could be avoided by just accepting both possible
interpretations of what an acknowledgement packet could be. This may not
help with interoperability with previous wpa_supplicant/hostapd
versions, but it may allow some other combinations to work and the more
strict validation does not really provide any real benefit.

> 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.

This should be resolved by accepting the single-octet ack frame with
Flags|Ver field. Would the tncs at fhh implementation accept both
alternative acknowledgement formats, i.e., would the interop issue be
resolved by just relaxing the validation rules in wpa_supplicant?

> If the assumptions about the flags field are incorrect, i would be glad
> if someone would enlighten me how to interpret it.

I'm not saying that they are incorrect, but there does seem to be more
than one way of interpreting what the TNC IF-T specification is
saying.. I'll send an interpretation request to TCG to both ask how this
should be interpreted and to ask it to be clarified in a future revision
of the specification.

-- 
Jouni Malinen                                            PGP id EFC895FA