CC3235MODSF: WPA2 Enterprise EAP-TLS Connection Issue

Ogulcan,

Firstly let's make sure your root of trust is correct. You indicated two root CAs above. If we look at this example - 

Offline Root CA

• Client Subordinate CA
• Client Certificate and Private Key

We need the Root CA, and the client cert and private key must have been derived by the same root CA. Can you confirm that?

BR,

Vince 

Hi Vince,

No, actually I indicated that there is only one Root CA which has two subordinate CAs.

But I can confirm that the client cert and private key have been derived by the Client Subordinate CA which is derived from the Root CA.

Here is a diagram of the 1 Root CA, 2 Subordinate CAs, 1 client certificate and 1 private key.

Best,

Ogulcan

Hi again,

Have you been able to take a look at the issue? Thanks.

Best,

Ogulcan

Hi Ogulcan,

Assuming that the client key/cert are signed by the subordinate CA, which is itself signed by the root CA, this should be the same topology as what we've encountered in the past.

At this point, looking at the NWP logs to see what is occurring at the CC3235 side during the EAP connect would be useful. If you could collect those logs during those connection failures that would be appreciated. Please see the instructions in section 20.1 of the NWP programmer's guide for details: http://www.ti.com/lit/swru455

The logs will be in a binary format if you have captured them correctly. This is normal, as the logs are only able to be decoded by TI. There is however a sanity check you can perform on your collected logs before you provide them to me. If the NWP logs are captured successfully from cold boot, you should see some ASCII plaintext in the raw logs, most notably the /sys/servicepack.ucf NWP SP file. Furthermore, the 3 bytes of binary data preceding that string will be 0x27 0xCA 0x2F. If you check for the string + those 3 bytes and see it in your logs then it should be captured correctly and decodable by my tools.

Regards,

Michael

Dear Michael,

Thank you for your answer. Yes, both subordinate CAs are signed by the same Root CA. I am not sure if this is relevant information but other devices with Windows OS uses the following configuration for successful connection. The Root CA must be installed under "Trusted Root Certification Authorities/Certificates". Both subordinate CAs must be installed under "Intermediate Certification Authorities/Certificates". Lastly, the client certificate must be installed under "Personal/Certificates". All 4 certificates are needed for successful connection with Windows OS. For the CC3235SF, I'm only able to provide "ca.der" and "client.der" for EAP-TLS connection. It is still not exactly clear to me which CA I need for the "sys/cert/ca.der". Is it the Root CA or one of the subordinate CAs? I assume you mean the Root CA is needed as "ca.der". What about the other subordinate CA? How does the CC3235SF client authenticate with the ISE (Authentication Server) Certificate Subordinate CA? According to Radius logs that seems to be the problem.

I know that the NWP logs are useful for you to understand the issue. I would have already provided them to you before you asked. However, as this is an integration with a customer that is abroad, unfortunately I do not have that option. I would appreciate if you could give me some feedback with current logs from Radius Server, Wireshark captures and Simplelink callback events.

Best,

Ogulcan

Hi again,

I have been using TI devices for my whole career in embedded systems. The biggest reason that I chose TI over and over again is the fact that how responsive and helpful TI support had been. However, it seems like this is not the case any more. I really hope that I will get a proper answer this time.

On the other hand, I have managed to capture NWP logs by creating the same environment of EAP-TLS connection in our office. I used randomly created certificates and the result is the same. SimpleLinkFatalErrorEventHandler receives SL_DEVICE_EVENT_FATAL_DEVICE_ABORT with code 2. I am attaching the logs here.

� -�-1
{�(����	9



�
�	-�-1
{�( 

Lc
�


�


�

�
�(
�

'�/sys/fips.cfg
��:��Ve(�Ze(-

�!
'�/sys/certstore.lst
��J
�

�
-��J
-��J�
-�	�J��
�$
�*��1
�
�	�
�*� *0{�A
\�M
�E*�""44v��
�*� ���C�1��
�
	��
L$
�
�

'�/sys/servicepack.ucf
���`
�

 ޻ B

�!
'�/sys/ucf_signatures.bin
��Ql-��Ql
-��Ql4-��Ql4T
-�	�Ql��

�

�!
'�/sys/servicepack.ucf
���`
�

-���`
!-���`-���`x-���`p
�
�
�

�
�

�
�
�
�

�
�

�

�
���,	�
�!
'�/sys/mode.cfg
���I-���I

-���I4-���I4�-�	��I
��-���`�\_�__
�*�@ *�Q �^*�� 
�
�

���i�
�i��i-�	��`�޻
��
nm)��
`aaA
	9	�)�-1
{�(	�!
'�/sys/certstore.lst	��J	�
	�
)��J
	�
)��J�
)�	�J��
	�

'�/sys/fips.cfg	��:��We(�[e(`a

aA			�

'�/tmp/crashminidump.bin	��+�1��1��1��	�!
'�/sys/mdmpcfg.ini	��I��y
e(	�!
'�/sys/pmcfg.ini	�I�)�I�

	�
)�I�4)�I�4
)�	I�	�>	a"0<bd�a	�	�

'�/sys/servicepack.ucf	���`	�

 ޻ B
	�!
'�/sys/ucf_signatures.bin	��Ql)��Ql
	�
)��Ql4)��Ql4T
)�	�Ql��
	�	�!
'�/sys/servicepack.ucf	���`	�

)���`
!	�
)���`)���`x)���`p	�	�	�
	�	�	�	�
	�)���`�	�	)�1	�!
'�/sys/ipcfg.ini	���)���

	�

)���4)���4�)�	���$
	�!
'�/sys/mode.cfg	���I)���I

	�

)���I4)���I4�)�	��I	��	Q
	�	�1�`  �1�`
 	 @M1�``V H1�`�k l1�`{ ��
1�`� � 1�`T' `1w@  �)	
1�`

�
	�		�	� 
	f	�		g	�!
'�/sys/fips.cfg	��:��y
e(/
-
	�	�		�!
'�/sys/devname.cfg	��c)��c

	�

)��c4)��c4b)�	�c	��			

	

	�	�	�	�	�)�G�
	�			�	�	�	
���5	�!
'�/sys/phypwr.cal	�e�A)�e�A
	�

	�	�	�	�

	P
	P	P	P	P	P 	P@	P�P
S�
	
	�	�		
	�)
�1	�!
'�/sys/macadd.bin	��q
�y
e(	5	V4	2$��v		
	�	�!
'�/sys/naptlv.bin	�2<�y
e(D
)���`|	�)���`��)���`�	�
	�
)���`�	�	�	�)���`��X*)���`�X*	�	�)�X*	�)���`C	�p)���`Cp	�)�	��`�޻	�	�	�	�)�p	�	�(	�	��	5%	�	�	�	�)��(	�)�e�A�8
)�e�A8
)�	e�A�8
	�	�	�)(��8
	��
��
	� 
	�	?	
	)
	
@�
��
�	
@l 	L
	L

	�	�	�	@	�

'�/sys/rxfltr.ini	�����We(�[e(	�

'�/sys/rxfltr.ini	�����We(�[e(�A
	�

'�/sys/rxfltr.ini	�����We(�[e(�A
�A
"�A

�A
�A
�A
�A
�A
�
B�B			�!
'�/sys/mdns.cfg	�[\�y
e(B�B��
B��A
�A
�A
�
B��
	�)C	
B		�!)
`
'�/sys/p2p.cfg	�o��y
e(	
	�	B:A	�		Q%
�,)h <��
!��		

D�!+


'�/sys/phybg.cal	��^�)�	)
)
)��^�
	�
)��^�t)�	�^��t�t	�
	<
	)			
	=	=	�
		(
	�	


�	q
	�!
'�/sys/date_time.cfg	�
>()�
>(
	�
)�
>(4)�
>(44)�	
>(	�h3�)'4)'
4).)):))'))?4)))*)r), de���), �����), ,
-
���), 
���
t
)i1`aaA	s)W$e�xV
.
�\��	6	)	
u
)0
	�!
'�/sys/stacfg.ini	�TU17)2�
	3
)�TU

	�
)�TU4)�TU4�)�	TU	��	K
	J#
	�#
	�!
'�/sys/pref.net	��)��
	�
)��4)��4,)�	��`	Y#test	�"test	�	�!
'�/tmp/chanhist.tbl	����y
e((a
1"D]'	E
	x��	T
	�	�

)XL*
 ��): 	")	��		J#	�#D	'	\
{
)
	�!
'�/sys/stacfg.ini	�TU)�TU

	�
)�TU4)�TU4�)�	TU	��SA	�6�)	�*"	 
	

	**")	�)T!���tim-�!



'�/sys/devname.cfg	��c)�)��c

	�
)��c4)��c4b	.$timH	r	)"
++)/#����
	0#timH>�	=)�	�c	��		
B�3j0
17)2�
	�	3
		�!
'�/sys/mdns.cfg	�[\�y
e(B�3j)0
17)2�
	�	3
6)	)	��'	�!
'�/sys/stacfg.ini	�TU)�TU

	�
)�TU4)�TU4�)�	TU	��	.$timH	r	)"
++)/#����
	0#timH>�	=	D]'	E
	dD'6�)	�)	2�)e$�S �h
�g
)e$
�g
�g
�g
�!


'�/sys/ipcfg.ini	���)p)���

	�
)���4)���4�)�	���$
62)	2)	���!

'�/sys/date_time.cfg	�
>()@
	.$test	r	)"
++)/#����
	0#test(a

A�test$a
1%�test
>�	=	z

	.$test	H		�"test	�	.$timH	r	)"
++)/#����
	0#timH>�	=	.$test	r	)"
++)/#����
	0#test(a

A�test$a
1%�test
>�	=	.$test	r	)"
++)/#����
	0#test(a

A�test$a
1%�test>�	=	.$timH	r	)"
++)/#����
	0#timH>�	=	.$test	r	)"
++)/#����
	0#test(a

A�test$a
1%�test>�	=)�
>(
	�
)�
>(4)�
>(44)�	
>(	�h
�		6�)	�)	f�6f�)	f)	��6�)	�)	���!



'�/sys/mode.cfg	���I)�	�)VL*
 ;
	T	r	)"
,,SA	�)���D]'	E
	x)���>�	=	T
	�	�

)XL*
 ��): D	')	()���I

	�
)���I4)���I4�)�	��I	��6�)	��!+


'�/sys/phya.cal	�r$	�
	�!�
))) )0)@)P�
 )�r$
	�
)	���!



'�/sys/stacfg.ini	�TU)		.$timS	r	)"
++)/#d����
	0#timS>�	=)�TU

	�)�TU4)�TU4�)�	TU	��6�)	�)	���!



'�/sys/stacfg.ini	�TU)	)�TU

	�)�TU4)�TU4�)�	TU	��6�)	�)	���!



'�/sys/mode.cfg	���I)�)���I

	�)���I4)���I4�)�	��I	��)*6�)	�)	��6�')	�)	��11��
H���h�	�1��x������������1����������<����1������2��������	�"test	�
Iq6�)	�	�)VL*
 ;
	T	r	)"
,,	�)�
��D]'	E
	x	�>�	=	T
	�	�

)XL*
 ��	:D	')	(	.$timH	r	)"
++)/#$����
	0#timH>�	=	.$timH	r	)"
++)/#$����
	0#timH>�	=	.$timH	r	)"
++)/#$����
	0#timH>�	=	.$timH	r	)"
++)/#$����
	0#timH>�	=	.$timH	r	)"
++)/#$����
	0#timH>�	=	.$timH	r	)"
++)/#$����
	0#timH>�	=	.$timH	r	)"
++)/#$����
	0#timH>�	=	.$timH	r	)"
++)/#$����
	0#timH>�	=	�)VL*
 ;
	T	r	)"
,,	�)���	Cx��(a
!�`G�7!!
"!1#Atest_ent>�	=	T	�	�

)

t		
	.$test	r	)"
++)/#����
	0#test(aA
�test$a
1%�test
>�	=	z

	.$test	H		.$timH	r	)"
++)/#����
	0#timH>�	=		r&&	)"
00!
1�test �
(a4��
"��>�	=	�		8#test	�
	L$test	M
4��
"��97!�`G	q	 	�
	


		�
	


	�
	�			�	�	
>�	=	 $
)��)��	r	)	#	�)V�*
 ;
	T	r	)"
,,	�>�	=)]"
d<)�"


	Z" 	�
		�)E	�	�
	!)"$P���=

)#����))	))))=	)
)0)1 
	�
	!	r!!>�	=	r  >�	=	r>�	=	,	r	)"
>�	=97!�`G), egD���), -
.
h���), 
h���), h���	*?"	r""	)"
), gl����), ����), ����), lh����), .
/
����), ����), ����), ����), ����), /
1
����	 #
P��)��	 
), 1
0
����>�	=?"	r""	)"
), 0
/
����), ����), ����	�
)-����	�

'�/sys/cert/client.der	�\��	�!
'�/sys/cert/client.der	�\��)�\��	�

)�\��W)�	\���W	�	�$C=TR	�

'�/sys/cert/private.key	�ٷ	�!
'�/sys/cert/private.key	�ٷ)�ٷ	�

)�ٷ�)�	ٷ��), 4���	�	�)-
����	�), ����), ����), /
1
����	 #BP��)��	 B), 1
0
h���>�	=!?"�	r""	)"
), 0
/
4���), 4���), 4���	�), ����), x���), /
1
x���	 #
P��)��	 
), 1
0
X���>�	=!?"�
	r""	)"
), 0
/
@���), @���), @���)-@���)-���)-���)-���	�

'�/sys/cert/client.der	�\��	�!
'�/sys/cert/client.der	�\��)�\��	�

)�\��W)�	\���W	�	�$C=TR	�	�

'�/sys/cert/private.key	�ٷ	�!
'�/sys/cert/private.key	�ٷ)�ٷ	�

)�ٷ�)�	ٷ��LLLLLLLL�	��+���	�
��%
�			�	� 
��
��
/L

Please let me know what is the issue here.

Best,

Hi,

Thanks for providing the NWP logs.

Looking through them, it appears that the NWP asserts right after the client private key is read. Have you double-checked to ensure that it is formatted correctly? If you could provide me the set of cert/key or provide instructions on how you generated the ones you are using so I can reproduce on my end that would be great.

Regards,

Michael

I have tried creating the client cert/key with different sub CAs but the result is the same. As I have mentioned previously, the client certificates are created on Windows OS in p12 or pfx format. Later, I am using openssl command "openssl.exe pkcs12 -in certificates.pfx -out certificates.cer -nodes" to convert it to PEM (ASCII) format. This "certificates.cer" contains Root CA, sub CA, client cert and client private key. I copy each part in a text editor starting with "-----BEGIN ***" and ending with " -----END ***" to a new file and save them with the corresponding naming; "ca.der", "client.der", "private.key".

You can find a set of example certificates and key attached.

1018.certs.zip

The User Guide says that the private.key can be in PEM(ASCII) or DER(binary) format. I always used the PEM format but I will try binary format as well.

Best,

During debugging, I found out that if I disable TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (basically the ones with 3DES) from accepted cipher suites device reacts different than before. I receive SimpleLinkWlanEventHandler, event SL_WLAN_EVENT_DISCONNECT with code SL_WLAN_DISCONNECT_UNSPECIFIED.

Disabling the above cipher suites on the Radius Server TLS settings, causes the Radius server to send an Access reject. Here is a snapshot of the comparison.

Also looking at the Radius logs I am comparing the Access request from a Windows OS laptop and TI CC3235SF. It looks like while the laptop ClientHello message is TLS v1.2, the one from the CC3235SF is TLS v1.0. I though CC3235SF supported TLS v1.2 for enterprise connection. Here is a comparison of that as well:

I hope these are helpful for debugging the issue. Please let me know as soon as possible if you find the root cause of the issue, as this is a very urgent matter with our client. Hope to hear back from you soon.

Best,

Hi again,

It seems like TI support is not responsive or helpful at all when it comes to WiFi forum. After many days of debugging the issue, finally I was able to find the exact combination of how the files should be under "sys/cert" folder. Here are the things that I have found out:

1. "ca.der" file has to be the Root CA. If you add any chain certificate to this file (the sub CAs in our case), the Radius Server throws an unknown CA error and the access request is rejected.
2. "client.der" file has to be the full chain until the Root CA. If you put only the client certificate here, the Radius Server rejects the request. If anyone from TI support had mentioned me any suggestions about this, I wouldn't have had to try every single possibility of chain and or singular certificates.
3. This is the most important matter about the issue which solved the NWP assert. "private.key" MUST be in binary format! Even though, the documentation and forum posts say that any of these 3 files can be in binary or ASCII format, it is not true for the user key. I suggest TI engineers to investigate the reason behind this.
4. Any of these files MUST have Unix (LF) ending. I haven't seen this anywhere on the several CC3x20,CC3x35 documentations or Programmer's Guide but luckily it is mentioned in the Uniflash User's Guide.

Finally, I am able to connect to an Enterprise Network with EAP-TLS using these configurations. However, there is an issue which could still be a problem. Can you please tell me why do I see TLS v1.0 exchange with CC3235SF, while it is TLS v1.2 with Windows OS connection request? I have provided the comparisons and screenshots on my previous post. I hope to get an answer from you soon.

Best,

Ogulcan

Hi again,

After testing my idea, if I disable TLS v1.0 on the Radius Server, the authentication fails for CC3235SF. The reason for disconnection is SL_WLAN_DISCONNECT_UNSPECIFIED. I am adding the Radius logs here:

(41) eap: Peer sent packet with method EAP TLS (13)

(41) eap: Calling submodule eap_tls to process data

(41) eap_tls: Continuing EAP-TLS

(41) eap_tls: Got final TLS record fragment (56 bytes)

(41) eap_tls: WARNING: Total received TLS record fragments (56 bytes), does not equal indicated TLS record length (0 bytes)

(41) eap_tls: [eaptls verify] = ok

(41) eap_tls: Done initial handshake

(41) eap_tls: (other): before SSL initialization

(41) eap_tls: TLS_accept: before SSL initialization

(41) eap_tls: TLS_accept: before SSL initialization

(41) eap_tls: <<< recv UNKNOWN TLS VERSION ?0304? [length 0033]

(41) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal protocol_version

(41) eap_tls: ERROR: TLS Alert write:fatal:protocol version

tls: TLS_accept: Error in error

(41) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol

(41) eap_tls: ERROR: System call (I/O) error (-1)

(41) eap_tls: ERROR: TLS receive handshake failed during operation

(41) eap_tls: ERROR: [eaptls process] = fail

(41) eap: ERROR: Failed continuing EAP TLS (13) session.  EAP sub-module failed

(41) eap: Sending EAP Failure (code 4) ID 1 length 4

(41) eap: Failed in EAP select

(41)     [eap] = invalid

(41)   } # authenticate = invalid

(41) Failed to authenticate the user

(41) Using Post-Auth-Type Reject

(41) # Executing group from file /etc/freeradius/3.0/sites-enabled/default

(41)   Post-Auth-Type REJECT {

(41) sql: EXPAND .query

(41) sql:    --> .query

(41) sql: Using query template 'query'

rlm_sql (sql): Reserved connection (10)

It is mentioned here that it could be an issue about the TLS v1.3 but CC3235SF documentation says the maximum supported version of TLS is v1.2 which I can also see in the code.

I hope that this information is useful.

Best,

Ogulcan

Lastly, I tried using the following function to force TLS v1.2 but the result is the same. CC3235SF still uses TLS v1.0 to send EAP-TLS certificates and key.

    static SlSockSecureMethod_t method;
    method.SecureMethod = SL_SO_SEC_METHOD_SSLv3_TLSV1_2;                                 // security method we want to use
    SockID = sl_Socket(SL_AF_INET,SL_SOCK_STREAM, SL_SEC_SOCKET);
    Status = sl_SetSockOpt(SockID, SL_SOL_SOCKET, SL_SO_SECMETHOD, (_u8 *)&method, sizeof(method));
    Display_printf(display, 0, 0, "sl_SetSockOpt %d ret: %d\n\r", SL_SO_SECMETHOD, Status);

    static SlSockSecureMask_t cipher;
    cipher.SecureMask = SL_SEC_MASK_SECURE_DEFAULT;                 // cipher type
    Status = sl_SetSockOpt(SockID, SL_SOL_SOCKET, SL_SO_SECURE_MASK,(_u8 *)&cipher, sizeof(cipher));
    Display_printf(display, 0, 0, "sl_SetSockOpt %d ret: %d\n\r", SL_SO_SECURE_MASK, Status);

Best,

Ogulcan

Hi Ogulcan,

It's interesting that you observe the CC3235 using only TLS1.0 when connecting to the radius server in EAP-TLS, instead of the TLS1.2 that it supports. This is something that has been reported by another E2E customer recently but was stalled on my need to setup the exact radius server setup to reproduce. I'm current running an older version of freeRadius that does not allow for a simple copy and paste of your settings from freeRadius v3+ unfortunately.

Given that there is another report of the same behavior, I will look into updating my freeRadius build on my EAP test setup, or otherwise getting this error to appear.

Regards,

Michael

Hi Michael,

I'm using FreeRADIUS Version 3.0.16. I've started with a clean build and only changed the following configurations in "etc/freeradius/3.0/mods-enabled/eap" file:

1. deafult_eap_type = tls
2. private_key_file, private_key_password, certificate_file, ca_file to corresponding files.
3. tls_min_version = "1.1"

If you do a clean build of FreeRADIUS and use these configurations, you will be able to reproduce the issue on your setup.

Also, I have started out with SDK 3.40 and service pack 4.4 for CC3235SF. During the tests I upgraded everything to the latest version, SDK 4.20 and service pack 4.7. Device acts the same so the problem is not solved.

Please let me know when you have updates.

Best,

Ogulcan

Hi Michael,

Do you have any update on the issue? Thanks.

Best,

Ogulcan

Hi again,

It would be nice to hear back from TI with some updates on the issue. At the very least, please give me a timeline on how you are going to solve this issue.

Best,

Ogulcan

Hi Ogulcan,

Thank you for providing those instructions to go from the clean setup of freeradius 3 to your setup that replicates the error.

I unfortunately haven't had the chance able to investigate this issue yet. I will give an update on this issue once i am able to work on it, most likely sometime next week.

Regards,
Michael

Hi Michael,

Thank you for your response. I would appreciate if you could increase the priority of this issue, as it is a very important security problem.

Best,

Ogulcan

Hi Michael,

Have you been able to work on the issue? I don't want this thread to be closed due to inactivity, as we both know that this problem still exists. Can you please give regular updates on the issue? Thanks.

Best,

Ogulcan

Hi Michael,

It has been more than a month since I have brought up this issue. It is really frustrating to not get any solution attempt ever since then. Even if you can't solve the issue, it would be great to receive some information about how this can or will be handled on your side.

I really hope to get a proper answer soon.

Best,

Ogulcan

Hi Vincent,

I have been expecting a solution for this issue for many weeks now. I assume that since the issue is about Enterprise, it concerns Michael. However, I haven't heard back anything for a very long time. Can anyone from TI let me know how this issue is going to be handled? Thanks.

Best,

Ogulcan

Hi Michael,

Here is another intention to get a response from TI on this issue. Can you please tell me what is the latest situation?

Best,

Ogulcan