Designing an EAP-TLS client hello message

Question

I am trying to design the first packet that initiates an EAP-TLS handshake. This is how my packet looks like currently:

enter image description here

The EAP part I have designed by manually filling a buffer in C with the respective information. The TLS part I derived using OpenSSL as shown in this question. Then I went to the RFC and added the 4 octet length field and TLS flags in the packet. But wireshark refuses to accept it! I tried comparing the TLS data byte by byte to a TLS connection happening over TCP, and I can see that the fields for client hello (16 in hex), TLS version (0x0301: TLS 1.0) are in the same order. Can you help me identify where am I going wrong? Thank you! Also, if anyone knows a client that can generate these messages so I can compare them, it would be beneficial too. Thanks!

What do you mean with "wireshark refuses to accept it"? Are you building only EAP, or also RADIUS packets? — Sergio A.
only EAP. Wireshark usually detects the fields in the client hello individually. for example, 0x0301 for TLS 1.0, 22 for handshake, etc. In case of my packet, wireshark only shows SSL and a chunk of data, like the one i have highlighted in the image, and is not able to decode the respective fields. — previouslyactualname

indiv indiv · Accepted Answer · 2014-07-11T23:45:12

Your 802.1X header says the packet is 227 bytes. You have 199 bytes highlighted and 28 bytes not highlighted, so that sums up to 227. Good.

So if your entire packet is 227 bytes, your EAP header certainly must be less than that. Except your EAP header says that the EAP data is 227 bytes, too.

Your EAP header should look like:

+------+------+------------+------+----
| code |  ID  |   length   | type | data ...
+------+------+------------+------+----
 1 byte 1 byte    2 bytes   1 byte  n bytes

RFC2716 says:

Length

  The Length field is two octets and indicates the length of the EAP
  packet including the Code, Identifier, Length, Type, and Data
  fields.  Octets outside the range of the Length field should be
  treated as Data Link Layer padding and should be ignored on
  reception.

So the length is the number of bytes starting at code and going to the end of the packet, which in this case I suppose would be 227 - 18 = 209.

Moving on, we see that the message type is 13, so it's an EAP-TLS packet. I see the S bit isn't set, which implies that this packet is a fragment acknowledgement. Is that correct? (probably not, but only you would know)

The S bit (EAP-TLS start) is set in an EAP-TLS Start message. This differentiates the EAP-TLS Start message from a fragment acknowledgement.

Getting to the EAP-TLS length, that tells us the total length of your message, in case your payload is spread out over many packets. Is the packet we're looking at your entire TLS message? Only you would know how long your message is and what its length is.

TLS Message Length

  The TLS Message Length field is four octets, and is present only
  if the L bit is set.  This field provides the total length of the
  TLS message or set of messages that is being fragmented.

I'm assuming the entire message is what you have highlighted, so its length would be 199.

Even if some of the details above are wrong for your packet, the general idea is that you've got the lengths wrong, and perhaps the flags are wrong, too.

Resources:

http://www.netcraftsmen.net/resources/archived-articles/429-examining-8021x-and-eap.html

http://www.ietf.org/rfc/rfc2716.txt

Designing an EAP-TLS client hello message

1 Answers