949c9ab9dd0503a07349ff0036fdc54c.ppt

- Количество слайдов: 34

ECE 454/CS 594 Computer and Network Security Dr. Jinyuan (Stella) Sun Dept. of Electrical Engineering and Computer Science University of Tennessee Fall 2011 1

IPsec: IKE Photuris and SKIP • PHASE 1 IKE • PHASE 2 IKE •

Security Association Issues How is SA established? ◦ How do parties negotiate a common set of cryptographic algorithms and keys to use? More than one SA can apply to a packet! ◦ E. g. , end-to-end authentication (AH) and additional encryption (ESP) on the public part of the network

IKE: Internet Key Exchange Purpose ◦ ◦ Mutual Authentication Shared Secret Establishment Crypto Algorithms Negotiation Security Association Establishment

IPsec Key Management Data transmitted needs to be secured ◦ IPsec SA, session keys, AH or ESP Messages for establishing IPsec SA need to be secured ◦ IKE SA, negotiated secret Negotiation for establishing IKE SA need to be authenticated ◦ Pre-shared secret key ◦ Public/private keys

Review: Cookies Clogging attacks First proposed in Photuris; Cookie Stateless cookies ◦ An opponent forges the source address of a legitimate user and send a public Diffie-Hellman key to the victim; The victim then performs a modular exponentiation to compute the secret key; Repeated messages of this type can clog the victim’s system with useless work. ◦ A number chosen by responder; When receiving a request from S, send the cookie to S in clear; start the processing after the cookie comes back from the initiator. ◦ The responder does not have to remember (store) the cookies he sent out; The cookie is a function of the IP address and a secret known to the responder

A Stateless Cookie Protocol

Photuris

Features of Photuris Denial of service protection: ◦ Stateless cookie CB in message 2 Signed Diffie-Hellman exchange ◦ Signature on the previous message in message 5 and 6 Identity hiding ◦ Anonymous Diffie-Hellman ◦ Identities are encrypted in message 5 and 6 (for active man-in-the-middle, the initiator’s identity is revealed, but not the responder)

SKIP: Simple Key Management for Internet Protocols SKIP uses long term Diffie-Hellman public keys ◦ Alice finds Bob’s public key (g. B mod p ) via a certificate from Bob or a directory. Bob finds Alice’s public key (g. A mod p ). Then they will have a common secret (g. AB mod p). Data encryption ◦ Long term common secret should not be used to encrypt data. Instead each message has a SKIP header where the long term secret is used to encrypt a short -term data encryption key, which is used to encrypt the message.

IKE Phases Phase One ◦ Mutual authentication ◦ Session key establishment ◦ ISAKMP SA/IKE SA Phase Two ◦ Negotiating IPsec SAs (AH, ESP)

Why two phases? ISAKMP would be used by other protocols to set up SAs, not only to set up IPsec SAs. Phase 1 exchange is relatively expensive. ISAKMP/IKE SA has a longer timeout period. It can be used to negotiate multiple phase 2 IPsec SAs, which reduces the usage of pre-shared secret or private key.

Phase 1 IKE Two modes Aggressive mode Main Mode ◦ 3 messages ◦ Mutual authentication ◦ Session key establishment ◦ ◦ ◦ 6 messages Mutual authentication Session key establishment Hiding endpoint identity Negotiating cryptographic algorithms

Phase 1: Aggressive Mode

Phase 1: Main Mode

Negotiating Cryptographic Parameters Encryption algorithm (e. g. , DES, 3 DES, IDEA) Hash algorithm (e. g. , MD 5, SHA) Authentication method (e. g. , pre-shared keys, RSA public key signature, DSS, RSA public key encryption) Diffie-Hellman group (e. g. , g and p)

Crypto Proposals Alice sends Bob a list of proposals, each consisting of an encryption algorithm, a hash algorithm, authentication method, and a Diffie. Hellman group. Bob replies one as the accepted proposal. The parameters in the proposal are used in Phase 1 and Phase 2 (IKE SA), with hash algorithm used for various purposes.

Key Types Mutual authentication based on ◦ Pre-shared secret key ◦ Public encryption key Original protocol design Improved Protocol design ◦ Public signature key

Cookie Issues IKE is stateful, starting from the first message. ◦ Alice’s crypto proposal is in the identity proof ◦ ISAKMP requires randomly chosen cookies Identifier: cookie>

Session Keys After Diffie-Hellman key exchange, each side knows gxy mod p Encryption key and Integrity key for the rest of IKE SA Keys for IPSec SAs

Session Keys Pseudo Random function – prf(key, data), e. g. , CBC residue, HMAC SKEYID ◦ For signature public keys, prf(nonces, gxy) ◦ For encryption public keys, prf(hash(nonces), cookies) ◦ For pre-shared secret keys, prf(pre-shared secret key, nonces) SKEYID_d: secret bits used to create other keys ◦ prf(SKEYID, gxy | cookies | 0) SKEYID_a: the integrity protection key ◦ prf(SKEYID, SKEYID_d | gxy | cookies | 1) SKEYID_e: the encryption key ◦ prf(SKEYID, SKEYID_d | gxy | cookies | 2)

Proof of Identity Proof of the key associated with the identity ◦ pre-shared secret key ◦ private encryption key ◦ private signature key Integrity-check on the previous messages, such as identity, Diffie-Hellman values, nonce, Alice’s crypto proposal, and the cookies.

Proof of Identity (Cont’d) Alice’s proof of identity ◦ prf ( SKEYID, gx | gy | cookies | Alice’s initial proposals | Alice’s identity ) Bob’s proof of identity ◦ prf ( SKEYID, gx | gy | cookies | Alice’s initial proposal | Bob’s identity )

IKE phase 1 protocols 8 phase-1 protocols ◦ 2 modes ◦ 4 types of keys Common features ◦ Message 1 starts with Alice’s cookie ◦ All other messages start with (initiator cookie, responder cookie), which serves as the IKE connection identifier

Phase 1: Public Signature Keys, Main Mode

Phase 1: Public Signature Keys, Aggressive Mode

Phase 1: Public Encryption Keys, Main Mode, Original

Phase 1: Public Encryption Keys, Aggressive Mode, Original

Phase 1: Public Encryption Keys, Main Mode, Revised

Phase 1: Public Encryption Keys, Aggressive Mode, Revised

Phase 1: Pre-Shared Secret Keys, Main Mode

Phase 1: Pre-Shared Secret Keys, Aggressive Mode

Phase 2, Quick Mode Establish IPSec SAs (e. g. , ESP and/or AH) All messages (except X, Y) encrypted and integrity protected ◦ Crypto parameters ◦ Diffie-Hellman numbers (optional) ◦ Traffic type (optional)

Reading Assignment [Kaufman] Chapter 18