1 / 81

Network Security Standardization at the IETF

Network Security Standardization at the IETF. IPsec and IKE Part 1. Contents Part 1. IKE Main Mode Quick Mode DOI Policies + Config General Structure and Properties of IKE Deficiencies of IKE IPSec SA, SAD, SPI: Receiving IPSec Packets SPD: Sending IPSec Packets IPsec Documents.

khanh
Download Presentation

Network Security Standardization at the IETF

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Network Security Standardization at the IETF IPsec and IKE Part 1

  2. Contents Part 1 • IKE Main Mode Quick Mode DOI Policies + Config General Structure and Properties of IKE Deficiencies of IKE • IPSec SA, SAD, SPI: Receiving IPSec Packets SPD: Sending IPSec Packets IPsec Documents

  3. Contents Part 2 • SoI Identities JFK IKEv2 Comparison • ESP + AH changes

  4. Internet Key Exchange (IKE) • ISAKMP Phases and Oakley Modes • Phase 1 establishes an ISAKMP SA • Main Mode or Aggressive Mode • Phase 2 uses the ISAKMP SA to establish other SAs • Quick Mode • New Group Mode • Authentication with • Signatures • Public key encryption • Two versions • Based on ability to decrypt, extract a nonce, and compute a hash • Pre-shared keys • Four of the five Oakley groups No SA Ph 1 Main Aggressive Ph 2 Quick New Group IKE states (simplified) modes and phases

  5. IKEMain Mode

  6. A B choose g,p generate x compute X=gx mod p X [,g,p] generate y compute Y=gy mod p Y IKE: Diffie-Hellman k= Yx mod p= (gx)y mod p= (gy)x mod p=Xy mod p =k

  7. A B choose g,p generate series of random numbers: Xi, i =1.. n Xi[,g,p] generate yi compute Yi=gyi(p) Yi IKE: Denial of Service: Flodding Exponentiation: computationally expensive Memory allocation

  8. A B CA choose CA X=gx mod p choose CB CB CA, CB, X [,g,p] Y=gy mod p CA, CB, Y IKE: Cookies • Return routability proof: • A has to have seenCB to send the next msg. If A spoofsAddiit has to sit on path Addi--B Close toAddi: not many active addresses Close toB

  9. A B CA choose CA choose g,p X=gx mod p choose CB CB CA, CB, X [,g,p] Y=gy mod p CA, CB, Y IKE: Cookies • If A uses repeatedly same Address: • Same cookie: B discards • Different cookies: A must wait • Problem remains: • Unauthenticated key-exchange: • man-in-the-middle

  10. A B CA choose CA X=gx mod p choose CB CB CA, CB, X [,g,p] Y=gy mod p CA, CB, Y IKE: Identities (Authenticated Key Exchange) CA, CB, {IDA}SAA,k CA, CB, {IDB} SAB,k • If A and B have a long-term security associations SA • (for instance, share a key PSKey) • they may use it, together with k (the D-H result) • to encrypt and authenticate the ID

  11. CA,ISAA A B CB,ISAB SKeyd = hSKey( k| CA | CB | 0) CA, CB, X [,g,p], NA SKeya = hSKey( SKeyd| k| CA | CB | 1) CA, CB, Y, NB SKeye = hSKey( SKeyd| k| CA | CB | 2) CA, CB,{IDA}PSKey,k HashA = hSKeya( X| Y| CA | CB | ISAA | IDA ) CA, CB,{IDB}PSKey,k IKE: Main Mode for shared key: Negotiation, Key Derivation SKey = hPSKey( NA | NB) {IDA}PSKey,k= (IDA | HashA ) • ISAA, ISAB are ISAKMP SA Data, used by IKE to negotiate: • encryption algorithm • hash algorithm • authentication method • The negotiated parameters pertain only to the ISAKMP SA • and not to any SA that ISAKMP may be negotiating on behalf of other services.

  12. IKEDeficiencies

  13. Designing key-establishment protocols • Needham-Schroeder (1978): first protocols, based on: • shared-key encryption • public-key signatures. (With on-line server rather than certication). • Needham andSchroeder also pointed out that the protocols are prone to subtle errors andthat there is a need for verication techniques. • Denning and Sacco (1981) found a flaw in the shared-key N-S protocol and proposed their own protocol that uses akind of name certicate issued by a trusted on-line server. • 10years later, Denning-Sacco protocol and the public-key Needham-Schroeder protocol were shown to have a serious flaws (Abadi–Needham 96, Lowe 96)

  14. Issues: 1.: Complexity • The cellular carriers haven’t seriously considered IKE to protect the Mobile IP messages due to the large overhead required in order to setup the IKE Security Association (large number of round trips). • IKE is a combination of 13 different subprotocols: • Phase One: 8 difierent subprotocols, • 2 choices for mode, and • 4 choices for authentication mechanism. • Phase Two: 4 difierent subprotocols: • perfect forward secrecy or no PFS • explicit identity information is included or not. • Plus new group protocol

  15. Issues: 1.: Complexity Marcus Leech, JeffSchiller, Steve Bellovin (Aug 2001): • A Cryptographic Evaluation of IPsec, Niels Ferguson and Bruce Schneier, http://www.counterpane.com/ipsec.pdf • Analysis of the Internet Key Exchange Protocol Using the NRL Protocol Analyzer, Catherine Meadows, http://www.itd.nrl.navy.mil/ITD/5540/publications/CHACS/1999/1999meadows-IEEE99.ps • IKE/ISAKMP Considered Dangerous, William Simpson, http://www.alternic.org/drafts/drafts-s-t/draft-simpson-danger-isakmp-01.html have shown security problems in IKE. „It seems only a matter of time before more analyses show more serious security issues [and] *implementation* problems become apparent. Reason: the complex nature of the protocol, and the complex implementation that must surely follow.“

  16. Issues: 1.: Complexity • Contradictions between the different documents: • Rekeing: multiple SAs may be pre-negotiated and used at will? • Possible interaction of the different subprotocols, which use similar formats, could lead to new insecurities. • This has been shown to be the case for an early version of SSL (draft-benaloh-pct-00.txt, 1995) • Intruder is able to pass off a compromised weak key as a strong key by interleaving two subprotocols, one of which uses the weak key, and one of which is intended to use a strong key.

  17. Issues with Identities in IKE (Meadows, 1999) • Client negotiation is supported. • The negotiating parties are not the endpoints for which security association negotiation is taking place. • The identities of the end parties remain hidden.

  18. Impersonation: IP Spoofing Session hijacking Man-in-the-middle Eavesdropping Msg modification Tunnel mode: the whole package is being encapsulated in a new package IPHdr IPHdr Fields Dest IPAdd Appl Hdr Payload Source IPAdd TCP Hdr Appl Payload IPHdr Payload Neuer IPHdr IPSec Hd IPHdr Payload IPSec Trailer encrypted There is also a less expensive Transport mode: new IPSec Header (+ evtl Trailer) provides somewhat less security IPHdr IPSec Hd Payload IPSec Trailer encrypted Insecured Messagesvs. Secured Messages

  19. IPHdr Payload IPSec Trailer encrypted IPHdr IPHdr Neuer IPHdr Payload IPSec Hd Payload Secured messages in an insecure environment Insecured messages in an secure environment Use of IPSec: Tunnel Mode

  20. Tunnel Mode • Tunnel mode has an “outer IP header” and “inner IP header” • AH protects part of the outer header as well • Authentication is between remote host and corporate firewall (or Security Gateway), or between two firewalls • User for access to entire internal network (VPN) or because the correspondent host has no IPSec stack IPHdr Payload • Transport Mode • Transport mode must be host to hostadequate for upper layer protocols • Gateways cannot handle fragmentation or multiple routes • Hosts share a secret key IPHdr IPSec Hd IPSec Trailer Neuer IPHdr IPSec Hd IPHdr Payload IPSec Trailer encrypted Payload encrypted Transport vs. Tunnel Mode

  21. Orig IPHdr Payload (e.g. TCP Hdr + Data) Orig IPHdr Payload (e.g. TCP Hdr + Data) AH Position Transport Mode Orig IPHdr AH Payload (e.g. TCP Hdr + Data) Authenticated (except for mutable fields) Tunnel Mode Neue IPHdr AH Orig IPHdr Payload (e.g. TCP Hdr + Data) Authenticated (except for mutable fields)

  22. Msg Authentication with HMAC Hash function H may be MD5, SHA-1, or, optionally, others • Goals are: • Use available hash functions and implementations • Preserve hash function performance, • Understand cryptographic strength • Allow easy replacement of the hash function if necessary • HMAC (H, K, T) = H(K  opad, H(K  ipad, T)) • K shared key, T text • opad is repeated bytes of 0x5C and • ipad is repeated bytes of 0x36.

  23. Authentication data field is calculated over • IP header fields that either do not change in transit (immutable) or that are predictable in value upon arrival at the endpoint for the AH SA. • Fields that may change in transit and whose value on arrival are unpredictable are set to zero for purposes of calculation at both source and destination. • Examples (IPv4): • immutable fields are Internet Header Length and Source Address. • mutable but predictable field is the Destination Address (with loose or strict source routing). • mutable fields are the Time to Live (TTL) and Header Checksum fields. • The AH header other than the Authentication Data field. • The Authentication Data field is set to zero for purposes of calculation at both source and destination. • The entire upper-level protocol data, which should be immutable in transit (e.g., a TCP segment or an inner IP packet in tunnel mode).

  24. Orig IPHdr Payload (e.g. TCP Hdr + Data) Encrypted Encrypted Authenticated Authenticated Orig IPHdr Payload (e.g. TCP Hdr + Data) ESP Position Transport Mode Orig IPHdr ESP Hdr Payload (e.g. TCP Hdr + Data) ESP Trail ESP Authn Tunnel Mode Neue IPHdr Orig IPHdr ESP Hdr Payload (e.g. TCP Hdr + Data) ESP Trail ESP Authn

  25. Encapsulating Security Payload • Encapsulating Security Payload (ESP) • encrypts data contents • format varies based on encryption type • Modes supported by ESP: • Tunnel mode: encrypt entire IP packet plus headers inside another IP packet • Transport mode: do not encrypt headers

  26. Security Association Database (SAD) SPI Dest. IP - Addr. Sec. Prot. Algorithm Key ... ... ... ... ... ... ... 375 2.2.2.2 AH HMAC - MD5 0110100... ... ... ... ... ... ... ... Security Associations (SAs) • Logically, a simplex “connection” that affords security services • Typical bi-directional security requires two SAs • Can be established by IKE or manual methods • Used by AH or ESP, not both • Technically, corresponds to one entry in the Security Association Database (SAD)

  27. Security Associations (SAs) • For inbound processing: The SA is uniquely identified by the 3 packet fields: • Security Parameters Index (SPI): The SPI assigns a bit string to this SA that has local significance only. The SPI is carried in AH and ESP headers to enable the receiving system to select the SA under which a received packet will be processed. • IP destination address: Currently, only unicast addresses are allowed; this is the address of the destination endpoint of the SA, which may be an end-user system or a network system such as a firewall or router. • Security protocol identifier: This indicates whether the association is an AH or ESP security association. • For the sender, these values are used to decide whether a given SA is appropriate for use with an outboundpacket. This is part of checking to see if there is an existing SA that can be used.

  28. Security Associations (SAs, cont.) • A SAdetermines the following values (= fields of the SAD): • Sequence number counter: A 32-bit value used to generate the sequence number field in AH or ESP headers • Sequence counter overflow: A flag indicating whether overflow of the sequence number counter should generate an auditable event and prevent further transmission of packets on this SA • Anti-replay window: Used to determine whether an inbound AH or ESP packet is a replay, by defining a sliding window within which the sequence number must fall • AH information: Authentication algorithm, keys, key lifetimes, and related parameters being used with AH • ESP information: Encryption and authentication algorithm, keys, initialization values, key lifetimes, and related parameters being used with ESP

  29. Security Associations (SAs, cont.) • A SAdetermines the following values (= fields of the SAD): • Lifetime of this security association: A time interval or byte count after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur • IPSec protocol mode: Tunnel, transport, or wildcard (required for all implementations); these modes are discussed later • Path MTU: Any observed path maximum transmission unit (maxi-mum size of a packet that can be transmitted without fragmentation) and aging variables (required for all implementations)

  30. SAD AlgorithmParameters Use of SPI, SAD: Receiving an AH-protected package Received IP packet Extraction Normalization SPI Normalized IP Packet AH Extraction Calculation ReceivedAuthn. Value CalculatedAuthn. Value yes no ?= Discard package Accept packageAuthentic senderInteger package

  31. Security Policies • For every packet that is to be sent out, the SPD (Security Policy Database) is checked to find how the packet is to be processed. The SPD can specify three actions: • discard, • bypass IPsec, or • apply IPsec processing. Result may be: • all trafic between two computers carried on a single SA, • separate SA used for each application or for each TCP connection. • The SPD also specifies which SAs should be used (if suitable SAs have already been set up) or specifies the parameters for a new SAs to be used.

  32. SPD: Security Policy Database • Packets are classified according to selectors • SPD matches selectors to determine the appropriate action. • API for creating entries in the security policy database is not standard: left to the IPSec or operating sys provider. (Only PF_KEY available: provides access to security associations for key management systems).

  33. SA Selectors • Each SPD entry is defined by a set of IP and upper-layer protocol field values, called selectors.Selectors are used to filter outgoing traffic in order to map it into a particular SA. Outbound processing obeys the following general sequence for each IP packet: • Compare the values of the appropriate fields in the packet (the selector fields) against the SPD to find a matching SPD entry, which will point to zero or more SAs. • Determine the SA (if any) for this packet and its associated SPI. • Do the required IPSec processing (that is, AH or ESP processing).

  34. SA Selectors • The following selectors determine an SPD entry: • Destination IP address: This may be a single IP address, an enumerated list or range of addresses, or a wildcard (mask) address. The latter two are required to support more than one destination system sharing the same SA (for instance, behind a firewall). • Source IP address: This may be a single IP address, an enumerated list or range of addresses, or a wildcard (mask) address. The latter two are required to support more than one source system sharing the same SA (for instance, behind a firewall). • UserID: UserID is used to identify a policy tied to a valid user or system name. • Data sensitivity level: The data sensitivity level is used for systems providing information flow security (for instance, "Secret" or "Unclassified").

  35. SA Selectors • Transport Layer protocol: This value is obtained from the IPv4 protocol or IPv6 Next Header field. This may be an individual protocol number, a list of protocol numbers, or a range of protocol numbers. • IPSec protocol (AH or ESP or AH/ESP): If present, this is obtained from the IPv4 Protocol or IPv6 Next Header field. • Source and destination ports: These may be individual TCP or User Datagram Protocol (UDP) port values, an enumerated list of ports, or a wildcard port. • IPv6 class: This class is obtained from the IPv6 header. It may be a specific IPv6 Class value or a wildcard value. • IPv6 flow label: This label is obtained from the IPv6 header. It may be a specific IPv6 flow label value or a wildcard value. • IPv4 Type of Service (TOS): The TOS is obtained from the IPv4 header. It may be a specific IPv4 TOS value or a wildcard value.

  36. SPD, SPI, SAD: Sending an AH-protected package

  37. IPSec Documents • Divided in seven groups: • Architecture (general issues, requirements, mechanisms) • Encapsulating Security Payload, ESP (packet form and usage for encryption and some auth) • Authentication Header, AH (packet form and usage for auth) • Encryption Algorithm (how different ones are used) • Authentication Algorithm (using algs for AH and ESP) • Key management • Domain of Interpretation • RFC 241: IP Security Document Roadmap

  38. IPSec New Drafts (incomplete) • IP Encapsulating Security Payload (ESP) • draft-ietf-ipsec-esp-v3-03.txt • The AES Cipher Algorithms and Their Use With IPsec • draft-ietf-ipsec-ciph-aes-cbc-04.txt • On the Use of SCTP with IPsec • draft-ietf-ipsec-sctp-03.txt • IPsec-NAT Compatibility Requirements • draft-ietf-ipsec-nat-reqts-01.txt • Negotiation of NAT-Traversal in the IKE • draft-ietf-ipsec-nat-t-ike-03.txt • UDP Encapsulation of IPsec Packets • draft-ietf-ipsec-udp-encaps-03.txt

  39. IPSec New Drafts (incomplete) • Security Properties of the IPsec Protocol Suite • draft-ietf-ipsec-properties-02.txt • The HMAC-SHA-256-96 Algorithm and Its Use With IPsec • draft-ietf-ipsec-ciph-sha-256-01.txt • Propsal for the IKEv2 Protocol • draft-ietf-ipsec-ikev2-02.txt • Just Fast Keying (JFK) • draft-ietf-ipsec-jfk-04.txt • Design Rationale for IKEv2 • draft-ietf-ipsec-ikev2-rationale-00.txt • IP Authentication Header • draft-ietf-ipsec-rfc2402bis-01.txt

  40. IPSec New Drafts (incomplete) • Son-of-IKE Requirements • draft-ietf-ipsec-sonofike-rqts-00.txt • Revised Use of Identity in Successors to IKE • draft-ietf-ipsec-revised-identity-00.txt • Features of Proposed Successors to IKE • draft-ietf-ipsec-soi-features-01.txt • The Internet IP Security PKI Profile of ISAKMP and PKIX • draft-ietf-ipsec-pki-profile-00.txt • Extended Sequence Number Addendum to IPsec DOI for ISAKMP • draft-ietf-ipsec-esn-addendum-00.txt

  41. Network Security Standardization at the IETF IPsec and IKE Part 2

  42. Contents Part 1 • IKE Main Mode Quick Mode DOI Policies + Config General Structure and Properties of IKE Deficiencies of IKE • IPSec SA, SAD, SPI: Receiving IPSec Packets SPD: Sending IPSec Packets IPsec Documents

  43. Contents Part 2 • SoI Identities JFK IKEv2 Comparison • ESP + AH changes

More Related