CIS TCOM 551 Computer and Network Security Slide Set

CIS/TCOM 551 Computer and Network Security Slide Set 6 Carl A. Gunter Spring 2004 CIS 551 Columbia University

Public Key Infrastructure l l Mutual authentication of participants in a transaction requires a system of identities. Principals are identified by public keys. These keys can be used for authentication, but only if “spoofing” is prevented. A PKI provides a basis for establishing trust.

PKI Systems ITU X. 509 (viz. IETF PKIX). l PGP “web of trust”. l DNS sec. l

X. 509 Part of the X. 500 series of standards: the ISO/ITU Directory. l Originally intended to support access control for the directory as part of the Directory Access Protocol (DAP). l Dominant candidate now for PKI to support electronic commerce, although adoption has been slow. l

X. 509 Certificates X. 509 certificates bind a subject to a public key. This binding is signed by a Certificate Authority (CA). Subject Name Subject Public Key CA Name CA Signature

Chaining Joe Smith Subject Joe’s Key Subject’s Key Philly CA Issuer Philly CA Key Pennsylvania CA Key USA CA

Certificate Distribution Certificate accompanying signature. l Directory service. l Ø DAP. Ø LDAP. Ø DNS SEC. Email (S/MIME and MOSS). l Primary technique: cut and paste from web pages! l

X. 509 Certificate Format (v 3) Required fields. l Optional fields. l

Required Fields Version of format (1, 2, or 3 currently). l Serial number. l Signature algorithm identifier. Examples: l Ø DSS with SHA hash. Ø RSA with MD 5 hash. Issuer (CA) X. 500 name. l Validity period (start and expiry times). l

Required Fields, Continued Subject X. 500 name. l Subject public key information. l Ø Algorithm identifier. Ø Public key value. l Issuer signature.

Optional Fields Issuer unique identifier. l Subject unique identifier. l Extensions. l Ø Extension type. Ø Critical/Non-critical. Ø Extension field value.

Certificate Revocation Lists Sometimes it is necessary to terminate certificates before their expiration time. l How does the relying party know that the certificate has been revoked? l Mitre report for NIST suggests certificate revocation will be the largest maintenance cost for PKI’s. l Many distribution strategies proposed. l

Semantics of CRL’s l Three certificates. Revoke 1. 2. 3. l Q says P is the public key of Alice. R says P is the public key of Alice. Q says R is the public key of Bob. Three kinds of revocation. 1. 2. 3. P is not the public key of Alice. (3 not 2. ) Q no longer vouches for whether P is the public key of Alice. (2 and 3. ) The key of Q has been compromised. (2 not 3. ) 1998 Fox and La. Macchia

Adoption of PKI l Problems Ø Ø Revocation User ability to deal with keys Registration (challenge for all authentication techniques) Weak business model l Areas of Progress Ø Ø Ø SSL Authenticode SSH Smart cards for government employees Web services

Overview of Network Security l Challenges: Ø Ø Ø Ø Sharing Complexity Scale Unknown perimeter Many points of attack Anonymity Unknown paths

Security in Layers 1. 2. 3. 4. 5. Physical Link Network Transport Application

Examples l Physical spectrum Ø Tempest l Ø Spread l Link Ø WEP Ø GSM l Network Ø Firewalls Ø IPSec Transport Ø l SSL and TLS Application Ø Ø Ø S/MIME XMLDSIG and WS security Access control systems for web pages, databases, and file systems

Network Layer Security HTTP FTP TCP IP/IPSec SMTP

Transport Layer Security HTTP FTP SMTP SSL or TLS TCP IP

Application Layer Security PGP S/MIME Kerberos SMTP TCP UDP IP SET HTTP

Division of Labor in the Internet Hosts Routers Networks

TCP/IP Protocol Stack Host Router Host Application Transport Network Link Physical

Communication Processing Flow App 1 App 2 App 1 Transport Network App 2 Transport Network Link Link Physical Phys Physical

Typical Patchwork App 1 App 2 App 1 Transport Network App 2 Transport Network Link Link Physical Phys Physical

Physical Layer Protection Issues l Hide signal Ø Spread l spectrum Emission security Ø Radio emissions (Tempest) Ø Power emissions

Encapsulation Link Layer Frame Link IP Network Layer Header TCP Transport Layer Header Application Link Application Layer Payload

One Hop Link Layer Encryption Host Router Host Application Transport Network Link Network Link

Link Layer Encryption Encrypted Link IP TCP Application Link

End-to-End Network Security Host Router Host Application Transport Network Link

Network Layer Transport Mode Link IP TCP Application Link Encrypted Link IP Hdr TCP Application Tlr Link

VPN Gateway Host Router Host Application Transport Network Link

Network Layer Tunnel Mode Link IP TCP Application Link Encrypted Link New IP Hdr IP TCP Application Tlr Link

Layer 3 Implementation Options l Location Ø Host Ø Network l Style Ø Integrated Ø Modular (for tunnel mode)

Modular Implementation: Bump In The Stack (BITS) App 1 App 2 Transport Network Transport Security Network Net + Sec Network Link

Modular Implementation: Bump In The Wire (BITW) App 1 App 2 Transport Security Transport Network Link

Implementation Options: Integrated on Host App 1 App 2 App 1 Transport App 2 Transport Net + Sec Network Net + Sec Link

Implementation Options: Integrated on Router App 1 App 2 App 1 Transport App 2 Transport Network Net + Sec Network Link

Network Security Location Options Application Transport Network Link End-to-End Transport Link Application Transport Network Link Voluntary Tunnel Link Application Transport Network Link Involuntary Tunnel

Transport Layer Security Host Router Host Application Transport Network Link

Transport Layer Encryption Link IP TCP Application Link Encrypted Link IP Link TCP RH IP TCP Application App Link

Message Processing Sequence App 1 App 2 Sec Transport Network Link

Application Layer Security Link IP TCP Application Link Encrypted Link IP Key ID TCP Application Link

Link Layer Security l Advantages: Ø Transparent to applications. Ø Hardware solution possible. Ø Can address especially vulnerable links (viz. wireless). l Disadvantages: Ø Hop-by-hop protection causes multiple applications of crypto operations.

Network Layer Security l Advantages Ø Transparent to applications. Ø Amenable to hardware. Ø Flexible. l Disadvantages Ø Makes routing more complex. Ø Flexibility introduces policy management and compatibility challenges.

Transport Layer Security l Advantages Ø Transparent to applications. Ø Exposing TCP enables compression, Qo. S. l Disadvantages Ø Probably implemented in software. Ø Exposing TCP risks Do. S

Application Layer Security l Advantages: Ø customize to application Ø no special protocol stack required: transparent to networking l Disadvantages: Ø hard to share between applications

Firewalls Filter Inside Filter Gateway Outside Filters protect against “bad” packets. A gateway machine restores needed services. Protect services offered internally from outside access. Provide outside services to hosts located inside.

Possible Firewall Architecture Gateway Hosts Routers Networks DMZ Internal Network “Demilitarized Zone” Filtering Routers External Network

Benefits of Firewalls Increased security for internal hosts. l Reduced amount of effort required to counter break ins. l Possible added convenience of operation within firewall (with some risk). l Reduced legal and other costs associated with sponsoring hacker activities. l

Costs of Firewalls l l l Hardware purchase and maintenance Software development or purchase, and update costs Administrative setup and training, and ongoing administrative costs and trouble-shooting Lost business or inconvenience from broken gateway Loss of some services that an open connection would supply.

Firewall Placement

Kinds of Firewalls Filtering: operates by filtering based on packet headers l Circuit: operates at the level of TCP l Application: operates at the level of the application l

Filtering Firewalls l Filtering can take advantage of the following information from network and transport layer headers: Ø Source Ø Destination Ø Source Port Ø Destination Port Ø Flags

IPv 4 Packet Format l IPv 4 (Version field set to “ 4”) Version Hlen TOS Ident Length Flags TTL Protocol Offset Checksum Source. Addr Destination. Addr Options(variable length) Other Headers and Payload Pad

TCP and UDP packets l Protocols support O. S. “port numbers”: UDP Src. Port Checksum TCP Dst. Port Src. Port Length Dst. Port Sequence. Num Acknowledgment HL Other Headers and Payload 0 Flags Advert. Wind. Checksum Urg. Ptr Options (variable) Other Headers and Payload

Three-Way Handshake

TCP State Transitions

SYN Filtering Their Client SYN Our Client Our Firewall Their Server SYN/ACK Our Server

Ports l l l Ports are used to distinguish applications and services on a machine. Low numbered ports are often reserved for server listening. High numbered ports are often assigned for client requests. l l l Port 7 (UDP, TCP): echo server Port 13 (UDP, TCP): daytime Port 20 (TCP): FTP data Port 21 (TCP): FTP control Port 23 (TCP): telnet Port 25 (TCP): SMTP Port 79 (TCP): finger Port 80 (TCP): HTTP Port 123 (UDP): NTP Port 2049 (UDP): NFS Ports 6000 to 6 xxx (TCP): X 11

Filter Example Action ourhost port block * * allow GW 25 theirhost SPIGOT * port * * comment we don’t trust these people connect to our SMTP port Apply rules from top to bottom with assumed default entry: Action ourhost port block * * theirhost * port * comment default Bad entry intended to allow connections to SMTP from inside: Action ourhost port allow * * theirhost * port 25 comment connection to their SMTP This allows all connections from port 25, but an outside machine can run anything on its port 25.

Filter Example Continued Permit outgoing calls to port 25. Action src allow {our hosts} allow * port * 25 dest * * port 25 * flags ACK comment our pkts to their SMTP their replies

When to Filter Router Inside Outside

On Input or Output l l Filtering on output can be more efficient since it can be combined with table lookup of the route. However, some information is lost at this stage such as the physical input port on which the packet arrived. This can be useful information to prevent address spoofing. Filtering on input can protect the router itself.

Recommend: Filter ASAP Action block allow src SPIGOT * GW port * * 25 dest * GW * port * 25 * comment we don’t trust them connect to our SMTP our reply packets port * 25 * comment subtle difference connect to our SMTP our reply packets Is preferred over: Action block allow src * * GW port * * 25 dest SPIGOT GW *

Example of a Pitfall Router Inside l Outside Filter output to allow incoming and outgoing mail, but prohibit all else. Action allow block l Apply dest * * * port 25 >= 1024 * comment incoming mail outgoing responses nothing else this output filter set to both interfaces of the router. Does it work? l Unintended consequence: allows all communication on high numbered ports!

Larger Example Outside A Gateway B Router Net 1 Net 3 Net 2

Security Policy l l Very limited connections through the router between GW and the outside world. Very limited, but possibly different, connections are permitted between GW and anything in Net 2 or Net 3. Anything can pass between Net 2 and Net 3. Outgoing calls only are allowed between Net 2 or Net 3 and the outside world.

Using Input Filters This is very difficult or impossible to achieve with output filtering only. l Example: how can output filters be used to ensure that a spoofed source from the outside does not make it appear that the packet goes from Net 2 to Net 3? l

Filter on Input to Interface A Action block allow src {net 1} {net 2} {net 3} * * * port * * * dest * * * GW {net 2} {net 3} port * * * 25 * * flags * * * ACK comment block forgeries legal calls to us replies to our calls

Filter on Input to Interface B Action allow block allow src GW GW GW port * * * dest {partners} {net 2} {net 3} * port 25 * * * flags ACK comment mail relay replies to inside calls stop other GW calls let GW call the world

Doing it with Output Filtering For a two-port router, input filtering on one port is the same as output filtering on the other. Y X Router Use two routers!

Two Routers, Same Rules B Router Gateway Router A Outside Net 2 Net 3

Application Level Gateways The gateway acts as an intermediary at the level of the application, receiving outgoing commands, relaying them, obtaining responses and relaying them back to the source. l Mail gateways are a typical example. l Very strong control over security, but l Special purpose software is required. l

Circuit Level Gateways Caller connects to a TCP port on the gateway and the gateway connects to a TCP port on the other side. It relays bytes, acting like a wire. l More general-purpose than applicationlevel but allows finer control than filtering only. l Example: valuable logs of connections can be kept. l

Secure Socket Layer (SSL) l Session protocol with: Ø Ø l l Server authentication. Client authentication optional. Integrity checksum. Confidentiality. Possibly the most important security-related ecommerce protocol. Connection sets up security parameters. Many sessions possible within a given connection. Current version TLS 1. 0 http: //www. ietf. org/rfc 2246. txt

X. 509 Key Est. Messages (Reminder) l l l Let DA = EB(k), r. A, LA, A. Let DB = r. B, LB, r. A, A Two messages: 1. A -> B : cert. A, DA, SA(DA) Check that the nonce r. A has not been seen, and is not expired according to LA. Remember it for its lifetime LA. 2. B -> A : cert. B, DB, SB(DB) Check the r. A and A. Check that r. B has not been seen and is not expired according to LB.

Real-World Protocols Evolution (versions, extensibility) l Interoperability (options, negotiation) l Error modes l

SSL Protocol Stack Handshake Change Cipher Spec Alert SSL Record Protocol TCP IP HTTP

SSL Record Content Type Major Version Minor Version Payload Length

Content Types Handshake l 1 byte 3 bytes 0 bytes Type l Content Change Cipher Spec Length 1 byte 1 l Alert 1 byte Level Alert l Opaque Content 1 bytes Higher-Level Protocol Content

Creating Opaque Content l l l Begin with application data. Fragment it into blocks of 2**14 bytes or less. Optionally compress the fragments. Add a message authentication code (MAC) to the compressed data to ensure integrity. Encrypt the data to ensure confidentiality. Add SSL record header (4 fields).

What Is Needed? Negotiation of cryptographic protocols. l Initial authentication. l Key exchange to set up: l Ø Bulk encryption. Ø MAC.

How is this Done? l l l The handshake protocol negotiates the protocols to be used for authentication and bulk encryption. The handshake protocol carries out initial authentication. The handshake protocol establishes a 48 byte pre-master secret. Ø Ø Client and server use this to derive a 48 byte master secret. The master secret is used to generate a key block of sufficient length to supply all needed cryptographic parameters.

MAC Calculation A MAC write secret, MACWS, is extracted from the key block. l A hash function H is selected: either MD 5 or SSH. l The MAC is defined as follows. l H( MACWS || pad 2 || H( MACWS || pad 1 || seq_no || SSLCompressed. type || SSLCompressed. length || SSLCompressed. fragment ))

SSL Key Exchange Protocols RSA l Fixed Diffie-Hellman l Ephemeral Diffie-Hellman l Anonymous Diffie-Hellman l Fortezza l

SSL Bulk Encryption Protocols Protocol (type, key length) l IDEA (block, 128) l RC 2 -40 (block, 40) l DES (block, 56) l 3 DES (block, 168) l Fortezza (block, 80) l RC 4 -40 (stream, 40) l RC 4 -128 (stream, 128)

SSL Handshake Protocol Phases Establish Security Capabilities l Server Authentication and Key Exchange l Client Authentication and Key Exchange l Finish l

Establish Security Capabilities Client Server Clie Time nt H r rve Se ello H

Client Hello 1. 2. 3. Highest version number understood by client. 32 -bit timestamp and 28 -bit nonce. Session identifier. Ø Ø 4. 5. Nonzero value: update parameters of existing connection. Zero value: new connection and session. Cipher. Suite list in order of preference. A Cipher. Suite is a pair consisting of a key exchange algorithm (as given earlier) and a Cipher. Spec. List of compression methods.

Cipher. Spec Cipher. Algorithm (as given earlier). l MACAlgorithm (SHA-1 or MD 5). l Cipher. Type (stream or block). l Is. Exportable (true or false). l Hash. Size: 0, 16 (for MD 5), or 20 (for SHA-1) bytes. l Key Material. l IV Size. l

Server Hello 1. 2. 3. Highest version number supplied by client and acceptable to server. Time and nonce from server (independent of same from client). Session identifier. Ø Ø 4. 5. If non-zero from client then same value from server. Otherwise proposed by server. First cipher suite proposed by client and supported by server. First compression method proposed by client and supported by server.

Server Auth & Key Exchange Client Server e cat ifi ert C Time r rve Se a ific ert E est qu Re te C S y Ke ver er nge cha x ello H one D Optional

Certificate List of x. 509 certificates. l Required for all protocols except anonymous Diffie-Hellman. l

Server Key Exchange Protocol-dependent keying material. l Needed for all except RSA and fixed Diffie-Hellman. l Example: in anonymous Diffie-Hellman this message consists of a prime number, a primitive root for it, and the Diffie-Hellman public key for the server. l

Certificate Requests a certificate type (e. g. DSS for ephemeral Diffie-Hellman). l Specifies a list of certificate authorities. l

Server Done l Indicates that all messages in the server authentication phase have been sent and server is now awaiting a client response.

Client Auth & Key Exchange Client Server Ce rti Time fica te Cli ent Ce Ke rtif y. E xch ang e Optional ica te R equ est Optional

Certificate l Client sends an X. 509 certificate as requested by server or sends a No Certificate Alert.

Client Key Exchange Protocol-dependent keying material. l Example: In RSA the client generates a 48 byte secret and encrypts it using the public key of the server (from the Server Key Exchange message). l

Certificate Verification Contains explicit verification of client certificate. l Client signs the hash of a concatenation of the master secret and handshake messages. l

Client Auth & Key Exchange Client Ch ang Time e. C Server iph Fin ish er S her Cip e C ang h h inis F pec S

Client and Server The Change Cipher. Spec message causes the Cipher. Spec to become active. This is not a handshake record, but a record in the Change Cipher. Spec protocol. l Each party sends the Finished message under the new Cipher. Spec. l The message contains hashes using MD 5 and SHA-1 containing the master secret and the handshake messages. l

Master Secret l The Master Secret is computed from the Pre-Master Secret as follows: Master. Secret = MD 5( Pre. Master. Secret || SHA(“A” || Pre. Master. Secret || Client. Hello. random || Server. Hello. random)) || MD 5( Pre. Master. Secret || SHA(“BB” || Pre. Master. Secret || Client. Hello. random || Server. Hello. random)) || MD 5( Pre. Master. Secret || SHA(“CCC” || Pre. Master. Secret || Client. Hello. random || Server. Hello. random))

Cryptographic Parameters l The remaining cryptographic parameters are computed by iterating the following pattern. Key. Block = MD 5( Master. Secret || SHA(“A” || Master. Secret || Client. Hello. random || Server. Hello. random)) || MD 5( Master. Secret || SHA(“BB” || Master. Secret || Client. Hello. random || Server. Hello. random)) || MD 5( Master. Secret || SHA(“CCC” || Master. Secret || Client. Hello. random || Server. Hello. random)) ||

Cryptographic Parameters Client write MAC secret. l Server write MAC secret. l Client write key. l Server write key. l Client write IV. l Server write IV. l

Alerts Unexpected message. l Bad MAC. l Decompression failure. l Handshake failure, unable to negotiate an acceptable set of security protocols. l Illegal parameter in handshake message. l Close notify. l

Alerts, Continued No certificate. l Bad certificate. l Unsupported certificate. l Certificate revoked. l Certificate expired. l Certificate unknown: an unspecified issue arose in certificate verification. l

Ipsec l Network layer security

IPsec Classification l Modes Ø Ø l l Tunnel Transport Ø Ø Protocols Ø Ø Authenticated Header (AH) Encapsulated Security Payload (ESP) Configurations Ø l End-to-end Concatenated Nested Principal elements Ø Ø Ø Security Associations (SAs) Internet Key Exchange (IKE) Policy

Typical Case S Client Internet G ESP S ESP Gateway Corporate Network S Server

Encapsulated Security Header and Trailer 0 -7 8 -15 16 -23 23 -31 Security Parameter Index (SPI) Sequence Number Initialization Vector Protected Data Pad Length Authentication Data Next Header

Security Association An SA describes the parameters for processing a secured packet from one node to another. l SAs are simplex: use one for each direction. l If more than one SA is used for a packet the applicable SAs are called an “SA bundle”. l

SA Parameters (ESP Only) Sequence number, Sequence number overflow, Anti-replay window l Lifetime l Mode l Tunnel destination l PMTU l Encryption algorithm (IV, etc. ) l Authentication algorithm l

Policy is not standardized in IPSec but certain basic functionality is expected. l A Security Policy Database (SPD) is consulted to determine what kind of security to apply to each packet. l The SPD is consulted during the processing of all traffic: l Ø Inbound and outbound Ø IPSec and non-IPSec

SPD Actions Discard l Bypass IPsec l Apply IPsec: SPD must specify the security services to be provided. l Ø For inbound traffic it is inferred from: destination address, protocol, SPI. Ø For outbound traffic this is done with a selector.

Selectors are predicates on packets that are used to map groups of packets to SAs or impose policy. l They are similar to firewall filters. l Selector support l Ø Destination and source IP addresses Ø Name (DNS, X. 509) Ø Source and destination ports (may not be available on inbound ESP packets; use inner header for inbound tunnel mode).

IPsec Processing: Inbound l l Use selectors in SPD to determine drop, bypass, or apply. If apply, determine whether an SA or SA bundle for the packet exists. Ø Ø l If yes, then apply all appropriate SAs before dispatching. If no, then create all necessary SAs. Apply these when done before dispatching. When creating SA determine scope of future use: this selection or all matching the SPD selector. Update SPD selectors accordingly.

IPsec Processing: Inbound If there are no IPsec headers check SPD selectors to determine processing discard, bypass, or apply. l If apply, then drop. l If there are IPsec headers, apply SA determined by SPI, destination, protocol. l Use selectors on result to retrieve policy and confirm correct application. l

Case Study l Ipsec nested tunnels as an approach to gateway security requirements.

End-to-End Security and Mandatory Tunnels Client Security Gateway First hop encryption Server Second hop encryption Examples: WTLS, cdma 2000, L 2 TP, Palm VII

Goals for a Security Protocol 1. 2. 3. If Client C receives content from Server S, then this is authorized by the policies of S and all of the security gateways between C and S If C receives content from S, then this content is encrypted and authenticated from end-to-end between C and S Simple setup and low-overhead enforcement

IPSec Strategy

Encapsulation l l AH headers for authentication and authorization of traversal. Use tunnel mode. ESP header for authentication and confidentiality of end-to-end communication. Use transport mode. IP AH IP ESP TCP 20 24 20 8 20 payload ESP 16

Drawbacks to IPSec Solution § § Requires complex configuration using nested tunnels to establish security associations between client, gateways and server. Encrypts the TCP header limiting use of VJC and other similar compression techniques. Setup is relatively costly as session keys must be exchanged. Nested headers introduce significant bandwidth overhead.

IP SEC Header Overheads for 576 Byte Packets # SGs TCP + VJC 0 7% 1 22% 31% (4. 50 + 7. 61 t) 2 39% 49% (60. 8 – 5. 25 t) 3 61% 70% 4 88% 97% Security overhead =

Evidence of Problems Experimental: Free. BSD IPSec showed an overhead of 46% with two gatekeepers. l Standards activity: secure L 2 TP overheads were so severe a standard was developed specifically to reduce them. Default security with one gatekeeper yielded this: l IP ESP UDP L 2 TP PPP IP ESP TCP Payload ESP

Internet Key Exchange l l Motivating problem: Security settings (SAs) must be highly configurable Solutions: Ø Ø l l Let network administrator manually configure SA (most common) Provide mechanism to allow automatic negotiation and configuration Can be found at: http: //ietf. org/internet-drafts/draftietf-ipsec-ikev 2 -13. txt IKEv 2 Current as of March 22, 2004

IPSec Motivating problem: Security settings (SAs) must be highly configurable l Solutions: l Ø Let network administrator manually configure SA (most common) Ø Provide mechanism to allow automatic negotiation and configuration

High-level view l Requester: Responder: l IKE_SA_INIT --> <-- IKE_SA_INIT l l IKE_AUTH --> <-- IKE_AUTH l Ø These are mandatory message exchange pairs, and must be executed in this order.

High-level view l Initiator: Responder: CREATE_CHILD_SA --> l <-CREATE_CHILD_SA l INFORMATIONAL --> l <-INFORMATIONAL l Ø These messages are optional and can be sent by either party at any time.

Usage scenarios l Tunnel endpoint - Tunnel endpoint (Security gateway - Security gateway) Ø Neither endpoint of the IP connection implements IPSec Ø Transparent protection Ø Endpoints announce addresses behind them Ø Packets sent in tunnel mode

Usage scenarios l Endpoint - Endpoint Ø Both implement IPSec Ø Can use transport or tunnel mode Ø Single pair of addresses is negotiated for packets to be sent over this SA Ø If NAT is used, must UDP encapsulate in order to use port number to identify addresses “behind” NAT box

Usage scenarios l Endpoint - Security gateway Ø Ø Ø Probably used for remote access to secured network Packets sent using tunnel mode Outer IP header is source IP address (direct back to endpoint) Inner IP header is source IP address (through secure tunnel) Outer destination address is security gateway

IKE_SA_INIT Negotiates common cryptographic algorithm to use for the life of SA l Exchanges nonces l Performs Diffie-Hellman key exchange l

IKE_SA_INIT l Initiator: l HDR, SAi 1, Kei, Ni --> Ø HDR Responder: - SPIs, Version number, various flags Ø SAi 1 - supported crypto algorithms Ø KEi - Diffie-Hellman value (key material) Ø Ni - Nonce

IKE_SA_INIT l l Initiator: Responder: <-- HDR, SAr 1, KEr, Nr, [CERTREQ] Ø HDR - SPIs, version numbers, flags Ø SAr 1 - choice of crypto from SAi 1 Ø KEr - completes Diffie-Hellman exchange Ø Nr - nonce Ø [CERTREQ] - optional certificate request

Encryption Now both parties have enough information to compute a common SKEYSEED to derive all keys for IKE_SA l Call SK_e encryption key l Call SK_a authentication key l Call SK_d derived key (for CHILD_SAs) l Separate keys in each direction l

IKE_AUTH Authenticates IKE_SA_INIT by using private information from IKE_SA_INIT l Exchanges identities l Exchanges certificates l Establishes first CHILD_SA l

IKE_AUTH l Initiator: Responder: HDR, SK {Idi, [CERT, ] [CERTREQ, ] [IDr, ] AUTH, SAi 2, TSi, TSr} --> l Everything in {. . } is encrypted and integrity protected with SK l IDi - assert Initiator’s identity l AUTH - prove knowledge of secret corresponding to IDi l

IKE_AUTH l Initiator: Responder: HDR, SK {Idi, [CERT, ] [CERTREQ, ] [IDr, ] AUTH, SAi 2, TSi, TSr} --> l SAi 2 - begin negotiation of CHILD_SA l TSi, TSr - Traffic selectors (selection criteria for packets - entries from Security Policy Database associated with SA) l

IKE_AUTH l Initiator: Responder: <--HDR, SK {IDr, [CERT, ] AUTH, SAr 2, TSi, TSr} l IDr - asserts Responder’s identity l AUTH - authenticates identity l SAr 2 - completes negotiation of CHILD_SA l

Important Note l The recipients of IKE_AUTH messages must verify that all signatures and MACs are computed correctly and that the names in the ID payload correspond to the keys used to generate the AUTH payload

What have we accomplished? Both sides have assurance that they “know” who they are talking to l The created CHILD_SA has been instantiated with parameters based upon a set of shared secrets, and these parameters have been encrypted l

CREATE_CHILD_SA Used to create a new SA when one already exists, due to different security policy, SA expiration l Similar to IKE_AUTH, without any authentication processing l Either side can initiate at any time l Use SK_d for new key material l

INFORMATIONAL Used to convey control messages due to errors, notifications, or configuration changes l Node should audit half-open connections periodically and close them, but may not reuse SPIs l

Other Issues Initiating node is completely responsible for retransmission if timeout occurs l Use Message IDs for replay protection l Node can not rely on out-of-band routing information (ICMP) due to possible Do. S attack l

Other Issues Nodes must be willing to accept multiple responses on IKE_SA_INIT since they are not cryptographically protected, and any intercepting node can respond l IKEv 2 is highly forward compatible l Rekeying can occur at any time from either side (no set agreed lifetime) l

Changes from IKEv 1 l l 4 initialization messages instead of 8 Decrease latency in common case of 1 CHILD_SA by piggybacking this onto initial message exchanges Protocol is reliable (all messages are acknowledged and sequenced) Responder does not have to commit state until initiator proves it can accept messages

Potential Do. S Threat? l Computing keys, MACs, signatures is expensive (State, CPU exhaustion) Ø Carry no state unless initiator responds correctly to IKE_SA_INIT, IKE_AUTH Ø Can still mount attack by sending a number of valid IKE_SA_INITs, IKE_AUTHs (DDo. S likely) Ø Possibility: Selective verification on IKE_SA_INIT?