How does the supplicant connect to the auth server in EAP TTLS?



  • I understand that a tls has to be established between the supplicant (end user device) and the auth server but a few things are unclear :

    1. How does the supplicant know the ip adress of the auth server ?
    2. The supplicant is not granted access yet it has to communicate with tls, does that mean it is granted a temporary local ip address and only requests to the auth server are forwarded via usual NAT by the access point ?
    3. How does the supplicant authenticate the server ? If I were connecting to a website, I would chech the common name (and that the chain is correct up to a root CA certificate I have), but what would the supplicant check for in common name (subject) ?


  • Protocol stack

    As explained in section 5 of the draft, the supplicant does not use TCP/IP for the TLS communication. The TLS communication is done over EAP.

    +--------------------------------------------------------+
    | User Authentication Protocol (PAP, CHAP, MS-CHAP, etc.)|
    +--------------------------------------------------------+
    |          Inner Application extension to TLS            |
    +--------------------------------------------------------+
    |                       TLS                              |
    +--------------------------------------------------------+
    |                     EAP-TTLS                           |
    +--------------------------------------------------------+
    |                       EAP                              |
    +--------------------------------------------------------+
    | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.)  |
    +--------------------------------------------------------+
    

    For WPA, the communication is done over EAPOL:

    +--------------------------------------------------------+
    | User Authentication Protocol (PAP, CHAP, MS-CHAP, etc.)|
    +--------------------------------------------------------+
    |          Inner Application extension to TLS            |
    +--------------------------------------------------------+
    |                       TLS                              |
    +--------------------------------------------------------+
    |                     EAP-TTLS                           |
    +--------------------------------------------------------+
    |                       EAP                              |
    +--------------------------------------------------------+
    |                      EAPOL                             |
    +--------------------------------------------------------+
    |                       LLC                              |
    +--------------------------------------------------------+
    |                      Wifi                              |
    +--------------------------------------------------------+
    

    Notice how there is no TCP/IP involved.

    The Access Point is responsible to relaying the TLS communication to the TTLS authentication server.

    The network stack would look like this:

    [ CHAP     ]<---------------------->[ CHAP     ]
    [ TLS      ]<---------------------->[ TLS      ]
    [ EAP-TTLS ]<---------------------->[ EAP-TTLS ]
    [ EAP      ]<---------------------->[ EAP      ]
                           [ RADIUS ]<->[ RADIUS   ]
                           [ TLS    ]<->[ TLS      ]
    [ EAPOL    ]<->[ EAPOL | TCP    ]<->[ TCP      ]
    [ LLC      ]<->[ LLC   | IP     ]<->[ IP       ]
    [ Wifi     ]<->[ Wifi  | ...    ]<->[ ...       ]
     Supplicant     Access Point         RADIUS
                                         Server
    

    Here is packet analysis for a similar method (EAP-TLS) by WireShark (see PCAP file😞

    WireShark packet analysis

    Authentication

    On NetworkManager, the setup look like this:

    NetworkManager configuration

    In particular, you have to:

    • configure the CA certificate used for authenticating the EAP-TTLS server;
    • choose the domain name (or domain name suffix) of the EAP-TTLS server.


Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2