CC3135: Enterprise server authentication

Part Number: CC3135

Tool/software:

I have a setup with the cc3135 configured for enterprise security using PEAP-MSCHAPv2, and I am testing the server authentication feature. I have two root CA certificates with different keys but the same issuer and subject. One of them was used to sign the RADIUS server certificate, and the other was not. I confirmed this using the openssl verify command.

The issue is that authentication succeeds with both certificates. On the other hand, when I generated a fake root CA certificate with the same DN and CN using OpenSSL, authentication failed.

My questions are:

  • How can authentication succeed with two different root CA certificates?

  • What exactly is verified during server certificate authentication?

Using SP 4.4.1.4_3.1.0.5_3.1.0.19

  • Hi Michael,

    Please allow me to update you by Wednesday for your first question.

    For your second question, please see this thread

    Thank you,

    Brandon Liu

  • Hi Michael,

    Just a quick question. Do you use API sl_WlanSet(SL_WLAN_CFG_GENERAL_PARAM_ID,SL_WLAN_GENERAL_PARAM_DISABLE_ENT_SERVER_AUTH...)? How parameter is set?

    to : that thread is related to TLS socket not a EAP security authentication agistment RADIUS server.

    Jan

  • Hi Jan,

    Thank you for mentioning that.

    I was more trying to touch upon certificate authentication. 

  • The parameter is being set as follows:

    uint8_t param = 1;

    LOGT_D("enabling server authentication");
    sl_WlanSet(
    SL_WLAN_CFG_GENERAL_PARAM_ID,
    SL_WLAN_GENERAL_PARAM_DISABLE_ENT_SERVER_AUTH,
    1,
    &param);

    The documentation says otherwise, but If I remember correctly, there was a typo and 1 is correct value to enable the authentication

  • Hi,

    Update: Sorry for a wrong answer. Disabling of CA authentication is by parameter settings to 0. That means parameter 1 is correct at your case. Can you comment that code just for a test?

    Jan

  • Hi Jan

    I will check it again, but it seems 3 years ago you suggested the opposite..

  • Hi,

    Yes, I know. My bad. Please try comment that code and test again.

    At the past I tested EAP security with CC3220 and FreeRADIS and it worked properly. But maybe there can be issue related to CC3135/CC3235. I am not sure.

    When you set wrong time did verification fail due to expired CA file?

    Jan

  • Hi Jan

    Did some tests with bogus root CA cert. With SL_WLAN_GENERAL_PARAM_DISABLE_ENT_SERVER_AUTH parameters set to 0 or not set at all, sl_WlanConnect always succeeds regardless whether time set correctly or outside "not before"/"not after". Also succeeds with no certificate.
    However when SL_WLAN_GENERAL_PARAM_DISABLE_ENT_SERVER_AUTH parameters set to 1, connection fails with reason 208 when time set correctly, fails with reason 210 when time set outside "not before"/"not after" and fails with reason 209 when there is no certificate.
    So setting SL_WLAN_GENERAL_PARAM_DISABLE_ENT_SERVER_AUTH to 1 enables server authentication.

  • Hi,

    Yes, in past I tested multiple sceneries with certificates and it worked properly at CC3220. But I did not tested with CC3x35. At my old documentation I found this notes about error codes via WlanDisconnectEvt handler (sorry for typos but I quickly translating notes from Czech to English):

    Code=208:

    • incorrect user or password for EAP (depending on the selected EAP mode)
    • it is not possible to verify the server against the uploaded CA file
    • private key error (for TLS EAP modes)
    • RADIUS server does not support TLS 1.0 for EAP
    • other error - e.g. RADIUS server is not running, incorrect RADIUS server configuration, unsupported method set, etc.

    Code=209:

    •  missing CA file in the file system
    • missing certificate in the file system

    Code=210:

    •  CA file expired

    Settings of parameter SL_WLAN_GENERAL_PARAM_DISABLE_ENT_SERVER_AUTH need to be done before every calling sl_WlanConnec(). When you set this parameter to 0, CA validation is disabled. That means connection will be successfully even with missing CA file in filesystem or not set time inside NWP RTC. If you want to have enabled CA validation, just do not call API SL_WLAN_GENERAL_PARAM_DISABLE_ENT_SERVER_AUTH. Yes, it is expected when you call sl_WlanConnect() that success is returned. Because by calling this API you just start connection attempt. And successful or not successfully connection is returned via asynchronous handler.

    What you saw during test is exactly what I saw before with CC3220.

    Back to your issue with wrong CA file. I think you will need to capture NWP log at both scenarios (with wrong and proper CA file). Maybe it could be also useful to provide CA files, private key and certificate. Because I don't have tool for decoding NWP log, you will need to want for TI answer. NWP log can be captured via UART connected to one of pins of CC3135. Some details about NWP log you can read at SWRU455 chapter 20.

    Btw ... can you test with latest ServicePack. Latest ServicePack you can get from CC32xx SDK (yes, it is weird latest ServicePack for CC3135 you can find at CC32xx, but don't ask me...)

    Jan

  • Hi Jan

    Thanks for the info, will try to get the logs. Just one question: what do you mean by "Settings of parameter SL_WLAN_GENERAL_PARAM_DISABLE_ENT_SERVER_AUTH need to be done before every calling sl_WlanConnect()" ?
    In some scenarios I call sl_WlanConnect() several times with different sets of credentials, does it mean each call need to be preceded by SL_WLAN_GENERAL_PARAM_DISABLE_ENT_SERVER_AUTH? I supposed it need to be configured once per sl_Start() as every non-persistent parameter

  • Hi,

    No. This API need to be call before each sl_WlanConnect() call. From SWRU455: The demand for server authentication can be canceled through the WLAN setting. Canceling this authentication is valid for a single manual connection only.

    Maybe this can explain behaviour which you see, if you call SL_WLAN_GENERAL_PARAM_DISABLE_ENT_SERVER_AUTH only once per sl_Start() "session".

    Jan

  • Thanks, Jan, this is important tip. And BTW, with the latest service pack the CA file problem disappears, and only the correct root CA authenticates the RADIUS server. Not that it solves my problem, but at least the picture is clear now. Thank you for your help!