+ All Categories
Home > Documents > Description Yoad

Description Yoad

Date post: 05-Mar-2016
Category:
Upload: tasleem-arif
View: 225 times
Download: 0 times
Share this document with a friend
Description:
Description Yoad

of 30

Transcript
  • IKE message flowIKE message flow always consists of a request followed by a response.It is the responsibility of the requester to ensure reliability.If the response is not received within a timeout interval, the requestor will retransmit the request or abandon the connection.

  • SA terminologyIKE-SA used to secure IKE communication.

    CHILD-SACreated by the IKE to be used in ESP or AH security.

  • The two IKE phasesPhase 1 Establishment of an IKE-SA Mutual authenticationCreation of the first CHILD-SA. (An expensive process which is done rarely)Phase 2 establishing additional CHILD-SAsand performing housekeeping functions

  • Phase 1Establishes an IKE-SA that includes shared secret information that can be used to efficiently establish Child-SAs.Performs mutual authentication Creates the first Child-SA

    Consists of two stages

  • Stage 1 - INIT

    Negotiates cryptographic algorithms

    Exchanges nonces

    Performs a Diffie-Hellman exchange

    Note: messages are not protected

  • INIT requestThe initiator sends the following message:HDR, SAi1, KEi, Ni

    HDR header contains SPI, version, flagsSAi1 states the cryptographic algorithms the initiator supportsKEi initiators DH value.Ni initiators nonce.

  • INIT responseThe responder sends the following message: HDR, SAr1, KEr, Nr [CERTREQ]

    SAr1 states the cryptographic algorithms the responder selected.KEr responders Difie-Hellman value.Nr responders nonce.CERTREQ optional certificate request

  • SKEYSEED generationEach party generates the SKEYSEED which is used to derive the keys used in IKE-SA.Notice: separate keys are computed for each direction

  • Authentication stageAuthenticates the previous messagesExchanges and proves identities Establishes the first CHILD-SA

    Messages are protected using the keys derived at the INIT stage.Identity protection is achieved

  • Authentication requestHDR, SK{ IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr }IDi initiators identityCERT, CERTREQ optionally presenting or requesting certificatesIDr specifiying the responders desired identity

    * SK{} indicates encription and integrity protection using SK_e and SK_a

  • Authentication requestHDR, SK{ IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr }

    AUTH authenticates the previous message and the initiators identity.(a digital signature over the first message)

    SAi2, TSi, TSr needed for first CHILD-SA

  • Authentication response HDR, SK{ IDr, [CERT,] AUTH, SAr2, TSi, TSr}IDr responders identityCERT presenting certificatesAUTH - authenticates the previous message and the resonders identity.SAr2, TSi, TSr - needed for first CHILD-SA

  • End of phase 1

    Signatures are verified

    First CHILD-SA is established

  • Possible DOS attackThe response to the first Phase 1 message involves expensive computationsThis can be exploited in a DOS attack where the attacker use IP Spoofing to flood the victim with requests to open connection.Can be solved using cookies

  • CookiesA Cookie is a field which is sent to the connection initiator. The initiator is expected to return the cookie. A returned cookie is a proof that the initiator can receive packets destined to the IP address he declared.

  • The use of cookiesWhen a responder detects many half-open connections, a new policy is used.Each new connection request that does not contain a valid cookie is rejected.The rejection message contains a cookie and a demand for this cookie in a future connection request.

  • Cookie demandsNo one but the creator can construct a valid cookieCheap to createNo resources needs to be allocated to handle each cookie

  • Cookie creationCookie = HASH( | IPi | SPI | TS)

    - a secret known only to the responderIPi IP address of the initiatorSPI included in the requestTS time stamp

    (A possible problem )

  • Phase 2Creating a new CHILD-SA:Relatively cheap operationCan be initiated by either endpoints Provides optional perfect-forward-secrecy

    All other information flow:Will be discussed later

  • CHILD-SA requestA CREATE_CHILD_SA request:HDR, SK{ SA, Ni, [KEi,] [TSi, TSr] }

    SA The initiators offers for the new SANi - Initiators nonceKEi a new DH valueTSi, TSr proposed traffic selectors

  • CHILD-SA responseA CREATE_CHILD_SA response:HDR, SK{ SA, Nr, [KEr,] [TSi, TSr] }

    SA The responder chosen SA offerNr - Responders nonceKEr A new DH value (if the request had a Kei)TSi, TSr selected traffic selectors

  • PFS in IKEReminder:Perfect forward secrecy means that once a connection is closed and its keys are forgotten, even someone who recorded all the data from the connection, and gets access to the long term keys used to protect it, cannot reconstruct the keys of a CHILD-SA that was created during the connection.

  • Achieving CHILD-SA PFSThe optional KE field in the establishment of a new CHILD-SA indicates that the keys created depend on a unique DH key exchange. Such keys achieve the PFS quality.

    Expensive procedure.Depends on two conditions

  • Generating keying materialIn the establishment of the IKE-SA a pseudo-random function (prf) is negotiated.

    The keying material for all SAs is derived from the output string of the prf.

  • Prf usageUsually the amount of keying material needed is greater then the prf output.The prf is used iteretively:Prf+ (K , S) = T1 | T2 | T3 | where:T1 = prf (K , S | 0x01)T2 = prf (K , T1 | S | 0x02)T3 = prf (K , T2 | S | 0x03)

  • IKE-SA keying materialAfter INIT (in Phase 1), SKEYSEED is calculated:SKEYSEED = prf (Ni | Nr , g^ir)

    Ni, Nr nonces of both partiesG^ir the DH key

  • IKE-SA keys derivedFive keys are derived.SK_d used in deriving CHILD-SA keysSK_ai, SK_ar authentication keysSK_ei, SK_er encryption keys

    Notice: different keys for each direction

  • IKE-SA keys deriviation{ SK_d , SK_ai , SK_ar , SK_ei , SK_er } = Prf+ (SKEYSEED , g^ir | Ni | Nr | CKY-I | CKY-R)

    CKY-I , CKY-R the cookie of both parties

  • CHILD-SA keying materialCreation without PFS:KEYMAT = prf+ (SK_d, Ni | Nr)

    Creation with PFS:KEYMAT = prf+ (sk_d, g^ir | Ni | Nr )

    g^ir is the DH key established for this CHILD_SA

  • CHILD-SA keying derivationAll keys needed for the SA created are derived from the KEYMAT(depends on the needs of the algorithms using this SA)

    Multiple SAs can be created at a single CHILD_SA negotiation.

    By: Yoad Yaron' "... nonce IDR . " --- ....notes


Recommended