TNC Fragmentation ACKs [diff included]

[arne.welzel at stud.fh-hannover.de]

On Sat, 13 Feb 2010, Jouni Malinen wrote:
> On Tue, Feb 09, 2010 at 03:11:36PM +0100, Arne Welzel wrote:
>
>> 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.

Thanks for the input, as the ACK packet was not clearly described in the 
IF-T specification I started looking at the EAP-... RFCs and formed my
assumption on what i could found there...

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

Unfortunately tncs at fhh will currently not accept an empty ack. It
interprets any message with payload < 1 as "something wrong". This
could however be changed in future versions. The changes I made to eap_tnc.c
were likewise and result in not accepting something with payload < 1.
As of the interop issue, relaxing the validation rules would lead
wpa_supplicant to accept ACKs from tncs at fhh. However, as soon as
wpa_supplicant needs to send an ACK (payload = 0) something will break,
Granted that the tncs at fhh implementation isn't change.

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

Thanks for your effort, it would be interesting to hear what they say,
but maybe they've done that already?

Found the following Internet Draft [1] which defines PT-EAP and at the
same time EAP-TNC. (?)

   PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods

   Abstract
     This document specifies PT-EAP, a Posture Broker Protocol identical
     to the Trusted Computing Group's IF-T Protocol Bindings for Tunneled
     EAP Methods (also known as EAP-TNC).

The fragmentation part is more verbose than in the IF-T specification:

    A party that receives an EAP-TNC message with the M flag set MUST
    respond with an EAP-TNC Acknowledgement message: an EAP-TNC message
    with no Data and with the L, M, and S flags set to 0. The party that
    sent an EAP-TNC message with the M flag set MUST wait for the
    EAP-TNC Acknowledgement packet before sending the next fragment.

This would clear things up?

[1] http://tools.ietf.org/html/draft-hanna-nea-pt-eap-00#section-3.3

Arne