eap-4 by liaoxiuli

VIEWS: 6 PAGES: 17

									             Problem with Compound
             Authentication Methods
                             Jesse Walker
                           Intel Corporation
                      ( jesse.walker@intel.com )
                            ACKNOWLEDGEMENTS:

          N.ASOKAN, KAISA NYBERG, VALTTERI NIEMI, HENRY HAVERINEN, NOKIA
        JOSE PUTHENKULAM, VICTOR LORTZ, FARID ADRANGI, INTEL CORPORATION
              BERNARD ABOBA, ASHWIN PALEKAR, DAN SIMON, MICROSOFT

November 18, 2002            IETF #55, ATLANTA                             1
Problem = Man-in-the-Middle Attacks

Compound Methods
    = Tunneled or Sequenced Methods
        • where there is no strong mutual authentication
        • where the keys derived from mutual authentication
          are not the keys used for ciphering the link
        • where tunnel termination is not on the real
          endpoints (client or server)
        • where the authentication protocol derives no keys

              We focus mainly on tunneled EAP
                   authentication methods
 November 18, 2002      IETF #55, ATLANTA                 2
    WLAN Man-in-the-Middle Attack
• Assumptions:
  – Rogue AP/Suppliant combo device acts as
   man-in-the middle
  – Real Supplicant/Server supports any
   unprotected EAP type without tunnel protocol

• Observations
  – WLAN Session stolen by the attack
  – EAP-TTLS, PEAP, PIC, PANA over TLS,
   XAUTH… all susceptible


 November 18, 2002   IETF #55, ATLANTA            3
       EAP-TTLS Normal WLAN Authentication
 Supplicant                    Authenticator
    Client                            AP                      TTLS Server                    AAA-H Server
  Wireless
  Station                                              EAP
                    802.1X                                        RADIUS


          EAP/Identity Request

          EAP/Identity Response (anonymous@realm)


                             Tunnel establishment

   Tunnel Keys Derived                                  Tunnel Keys Derived
                                     EAP Method inside Tunnel         EAP/Identity Request

           EAP/Identity Response (user id@realm)

                                                                   EAP/ Request / Method Challenge

           EAP/Response/Method Response

                                               EAP/ Success

Inner Method Keys Derived                           Tunnel Keys          Inner Method Keys Derived
                                                                                & Not Used
                 WLAN Session


        November 18, 2002                      IETF #55, ATLANTA                                      4
            EAP-TTLS based WLAN session stealing
                <- Rogue AP/Client ->
                                                                          TTLS                        AAA-H
   Client               MitM                       AP
                                                                          Server                      Server

                                                        EAP/Identity Request

                              EAP/Identity Response (anonymous@realm)

                                            Tunnel establishment
                    Tunnel Keys Derived                               Tunnel Keys Derived

                                            EAP-Method in Tunnel
                                                                                      EAP/Identity Request

    EAP/Identity Response (user id@realm)

                                                                               EAP/ Request / Method Challenge

   EAP/Response/ Method Response

                                                                                            EAP/ Success


Inner Method
                                                            Tunnel Keys            Inner EAP Method Keys Derived
 Keys Derived
                                                                                            & Not used
                              WLAN Session Stolen


        November 18, 2002                     IETF #55, ATLANTA                                              5
           PEAP/EAP-AKA WLAN Session Stealing
           <- UMTS Tower/ WLAN Terminal ->
Terminal             MitM                             AP                     WLAN                                   HSS
                                                                             Server

                            Establishing a PEAP tunnel (server authenticated)


                                 TLS-protocol based on network certificate



                                 1. (…, EAP-Request/Identity message,
    IMSI_Request                 …)


                            Secured by TLS tunnel (only server authenticated)
    IMSI
                            2. TLS(EAP-Response/Identity (IMSI))
                                                                                      2a. MAP(Send_Auth Params:
                                                                                      IMSI) [or DIAMETER]

                                                                                      2b. MAP (AKA authentication
                         3. TLS(EAP-Request/AKA-challenge (RAND, AUTN))               quintuplets)


    3. RAND, AUTN



    2. RES
                               2. TLS(EAP-Response/AKA-challenge (RES))



                                                           WLAN_Master_session_keys
                                                           (based on TLS tunnel keys)
                             Stolen WLAN link

     November 18, 2002                            IETF #55, ATLANTA                                                       6
             Tunnels Problem Analysis
• One-way authenticated tunnel
• Even secure inner methods are vulnerable when
  composed incorrectly.
• Man-in-the-middle can trick client into believing it is a
  server
• Session keys derived from tunnel protocol only.
• Keys derived in inner EAP method (e.g., Method Keys)
  are not used.
• Client policy of not always using tunnels causes failure
• Any Client EAP method not cryptographically bound to
  Tunnel Session Keys potentially vulnerable
• All non-ciphered/non-protected links fully vulnerable

  November 18, 2002     IETF #55, ATLANTA                     7
                Solution Requirements
•   Fixes to existing EAP methods not ok
•   Fixes to new EAP methods maybe ok
•   Fixes to Tunnel methods maybe ok
•   Should work for different tunnel termination
    models
•   Should not bring new requirements for other
    protocols (eg. RADIUS )
•   Forward Evolution for protocols with fix
•   Backwards compatibility for fixed protocols
•   Simplicity for fix (low compute costs & roundtrips)
•   Upgraded EAP Base protocol maybe ok

    November 18, 2002   IETF #55, ATLANTA             8
      EAP Methods classification
• Methods which support ciphering
  –Derive session keys
  –Do key distribution to Access points using
   RADIUS attributes
  –Eg. EAP-MSCHAPv2, EAP/SIM, EAP/AKA
                                         FIXABLE
• Methods which don’t support ciphering
  –Not protected
  –Eg. EAP-MD5
                     FIXABLE BY USAGE RESTRICTION
 November 18, 2002   IETF #55, ATLANTA          9
                     Solution Concept
• Compound MACs
  – MACs computed from safe one-way derivation from
    keys of all EAP methods
• Compound Keys
  – Bound Key derived using safe one-way derivation
    from keys of all EAP methods
• Additional strong mutual authentication round
  trip with acknowledged success message
  – Success Message with Client MAC
  – Success-Ack Message with Server MAC over Client
    MAC


 November 18, 2002       IETF #55, ATLANTA            10
        Man-in-the-middle attack failure with solution
                  <- Rogue AP/Client ->
                                                                                        TTLS                           AAA-H
    Client                   MitM                            AP
                                                                                        Server                         Server

                                                                     EAP/Identity Request

                                  EAP/Identity Response (anonymous@realm)


                                                    TLS Session establishment

                        Tunnel Keys Derived                                          Tunnel Keys Derived

                                                EAP-Method in TLS Protected Session                   EAP/Identity Request

        EAP/Identity Response (user id@realm)

                                                                                              EAP/ Request / Method Challenge

       EAP/Response/ Method Response

                                                                                                             EAP/ Success

Inner EAP Method Keys                                  Compound MAC Success                            Inner EAP Method Keys

                                                        Compound MAC Failure
                                                                                                  Crypto Binding
                                                                         Attack Detected

                                                                         No Keys Sent


                                      No WLAN Access

          November 18, 2002                            IETF #55, ATLANTA                                                     11
     Why cryptographic binding?
• Methods that use a weak keys
    1. MUST be used within a server authenticated tunnel, and
    2. MUST NOT be used without tunnel to authenticate same client
• #2 drastically reduces use of legacy auth. protocols
    – MUST NOT be imposed on protocols that use strong keys
• Tunneling protocols (PEAP, POTLS etc.) address #1
    – But they treat the inner protocol as a blackbox (any EAP type)
• Hence the need for optional binding of tunnel and EAP
  method
• This allows tunneling protocols to
    – generic: handle both weak and strong authentication methods
    – secure: avoid MitM attack
    – non-invasive: avoid imposing restrictions on strong methods



  November 18, 2002         IETF #55, ATLANTA                          12
      Recommendations to EAP WG
• Tunneled and Sequenced Protocols have
  evolved from NEED
• Problem needs to be fixed
• Best fix would be
  – in EAP base protocol, and
  – in tunneling protocols
• Recommend formation of design team to
  study proposed fixes and recommend
  solution for EAP base protocol

 November 18, 2002   IETF #55, ATLANTA    13
                     References

• Nokia Research Center
  – http://eprint.iacr.org/2002/163/
  – http://www.saunalahti.fi/~asokan/research/mitm.html




• Intel Corporation, Microsoft
  – http://www.ietf.org/internet-drafts/draft-puthenkulam-
    eap-binding-00.txt


 November 18, 2002     IETF #55, ATLANTA                     14
                    Backup




November 18, 2002   IETF #55, ATLANTA   15
Tunneled Methods Generic Model
               Front-end         Authentication              Authentication
Client
              authenticator          Agent                      Server

        Stage 1: Tunnel Method
         Server authenticated for
       secure tunnel establishment

      secure tunnel

                         Stage 2: Client Authentication Method
                           Performs Client/User Authentication



    Ciphered Link      Tunnel Keys
                          Terminology
                          Tunnel endpoint is authentication ”agent”
                          Authentication protocol endpoint is authentication ”server”
                          ”Front-end” authenticator is end of access link to be authenticated
                          Agent and Server may be co-located

November 18, 2002                IETF #55, ATLANTA                                              16
   Sequenced Methods Generic Model
               Front-end               Authentication          Authentication             Authentication
Client
              authenticator               Agent 1                 Agent 2                    Server

         Protocol Sequence 1
 Client AND/OR Server Authentication
                                                                                ….
                       Protocol Sequence 2
               Client AND/OR Server Authentication




                                                           …
                                    Protocol Sequence N
                            Client AND/OR Server Authentication

      Open Link             No Session Keys


                    Terminology
                    ”Front-end” authenticator is end of access link to be authenticated
                    Intermediate endpoint in sequence is an authentication ”agent”
                    Final authentication endpoint is authentication ”server”
                    Agents and Server may be co-located.
November 18, 2002                      IETF #55, ATLANTA                                           17

								
To top