IPv6 Security Workshop - usipv6.com€¦ · – RFC 3633 for prefix delegation ... • Reverse chains for 6to4 addresses and Teredo addresses are ... IPv6 Security Workshop 27June

IPv6 SecurityWorkshop

June 2004

Rene Esposito B | A | [email protected]

Richard Graveman RFG [email protected]

IPv6 Security Workshop 2June 2004

IPv6 Security: Outline

1. Internet Security2. IPv6 Core Protocols3. IPv6 Infrastructure Protocols4. Protocol Security: IPsec and IKE5. Firewalls for IPv66. Security and IPv6 Transition7. Summary


Security and the Internet When we first turned on extensive logging on our

gateway host, it was much like moving into a new house with a tin roof in a hail-prone neighborhood under several large oak trees during acorn season. We diligently chased down evil-doers and helped secure numerous open systems. Some corporate machines were secured as well.

Getting hacked is seldom a pleasant experience

Bellovin and Cheswick, Firewalls and Internet Security


Scope This talk covers

IPv6 protocol and infrastructure security IPsec, including recent draft changes IPv6-based denial of service attacks

Host and router system security only as related to IPv6 IPv6 firewalls Security of IPv6 transition strategies

It does not cover Overall security architecture Physical, environmental, or personnel security General system security Network applications, buffer overflows, viruses, worms, spam, Kernel implementation, Timers, Multicast Keying


What Do We Want from Security? We assume an adversary may get complete access to

our communications channels (i.e., were on the Internet): Read, write, replay, modify, reorder, rearrange, truncate, reroute,

spoof headers and addresses, etc. Try to take control of routers and hosts Launch additional attacks from compromised systems

We want: To know whos sending what we get To know whos reading what we send To know that no one else has tampered with it To keep the network available and working reasonably well To control our own equipment

Contents and operation; software and data


IPv6 and the Black Hat World IPv6 has been found running today without administrators

knowledge Can be enabled on many platforms (XP, 2000, Linux, etc.)

Intentionally by users or otherwise by intruders Can provide a stealth network for intruders

Harder to scan Evades many intrusion detection systems Has been caught in honeypots and post mortem analysis

Attacks on IPv6 can compromise co-existing IPv4 networks Precautions

Block protocol 41 Handle Teredo as a dangerous UDP port at IPv4 firewalls Look for Router Advertisements and Neighbor Discovery packets

ICMPv6 over layer 2


IPv6 Security: Outline1. Internet Security2. IPv6 Core Protocols3. IPv6 Infrastructure Protocols4. Protocol Security: IPsec and IKE5. Firewalls for IPv66. Security and IPv6 Transition7. Summary


IPv6 Core Protocols: Introduction

IPv6 can offer end-to-end connectivity to all hosts That, in itself, is scary to some who are used to NATs

IPv6 header is simpler But IPv6 extensions are much more flexible

IPv6 does much more than IPv4 at Layer 3 Some old favorites like ARP disappear Stateless Auto-Configuration is new IPv6 promotes Mobile IP


IPv6 Core Protocols: IPv6 Header Format

Flow Label(20 Bit)

Traffic Class(8 Bit)

Version(4 Bit)

Payload Length(16 Bit)

Next Header(8 Bit)

Hop Limit(8 Bit)

Destination Address(128 Bit)

Source Address(128 Bit)


IPv6 Core Protocols: IPv6 Extension Headers

Order of Extension Headers when more than one is used in same packet: IPv6 Header Hop-by-hop Options Header Destination Options Header (every Routing Header destination) Routing Header Fragment Header Authentication Header (AH) Encapsulation Security Payload (ESP) Header Destination Options Header (last Routing Header destination) Upper-Layer Header

TCP Header + Data Payload

IPv6 Header

Next Header =Routing

FragmentHeader

Next Header =Security (ESP)

Security Header (ESP)

Next Header =TCP

RoutingHeader

Next Header =Fragment


IPv6 Core Protocols: Addressing

Unicast, Multicast, Anycast IPv4 broadcast replaced by Multicast, Anycast IPv6 Multicast essential

Link local and site local scoping Link local makes a lot of sense Site local makes a lot less sense (today)

Effect of huge address space on subnets Address and port scanning a subnet can be a

lot harder


IPv6 Core Protocols: Address Generation and Renumbering

Auto-Configuration Getting on a LAN may imply having insider privileges Need to look at different cases

Enterprise, in the building 3GPP Public WiFi Ad hoc networking

Effects of self-generated addresses RFC 2462 addresses can be stolen by others RFC 3041 addresses cannot have pre-established IPsec keys and

may make ingress filtering harder SEND cryptographically generated addresses can be bound to a

public key Subnet renumbering

Need to track multiple prefixes simultaneously Need to map permissions from old to new addresses


IPv6 Core Protocols:IPv6 Anycast Security

Reserved anycast addresses may provide an attacker with a well known target Globally reachable anycast only defined for routers

No authorization mechanism exists for anycast destination addresses Spoofing and masquerade possible

IPsec hard to set up in advance IPsec security associations need destination address


IPv6 Core Protocols: Site-Local Addresses

IETF deprecated site-local addresses in March 2003 Intuitively, sites are hard to define Site boundaries may not match security, reachability, QoS,

administrative, and funding boundaries The same addresses (e.g., FEC0::1) can exist in many sites A multi-homed host can belong to a site per interface Developers have to handle site identifiers along with addresses Multi-sited routers have to remember arrival interface Addresses can leak in application-layer data

Replacement architecture will have unambiguous addresses and more flexible scope rules Firewalls will need to implement the new design and block the

old-style FEC0::/10 addresses


IPv6 Core Protocols: Flow Labels

Defined in RFC 3697 Associated with a source and destination address pair

Only main header; extensions, ports, etc. not used Rudimentary requirements

Intact delivery, reuse, timeout, proscribed uses Security considerations

Denial or theft of service No authorization mechanism

Interaction with tunneling and IPsec Cryptographic integrity checks can protect inner flow label

Traffic analysis may become simpler Firewalls cannot trust flow labels for decisions


IPv6 Core Protocols: ICMPv6 Capabilities implemented with ICMPv6

Address auto-configuration Router and prefix discovery Neighbor reachability and address resolution Duplicate address detection Router renumbering Redirect PMTU discovery Echo request and echo reply Error notifications

Examples of security questions Are Router Advertisements coming from an authorized router? Are there security requirements for Neighbor Advertisements? Are redirects coming from the router to which the packet was

actually sent?


IPv6 Core Protocols: Neighbor Discovery

Neighbor Discovery lacks a mechanism for determining authorized neighbors

Attacks: Redirection, stealing addresses, denial of service,

advertisement and parameter spoofing

Defenses: Using hop count 255 (RFC 3682) has limited value IPsec Authentication Header (AH) or Encapsulating

Security Payload (ESP) only works with manual keying and pre-established security associations


IPv6 Core Protocols: Summary of ICMPv6 Security

IPv6 RFCs say: Use IPsec AH for ICMPv6

But, how? Need addresses, which may not be

determined Need a Security Association and keys

Manual set up: how many? which ones? Automatically generated: need to run UDP


Summary: IPv6 Core Protocols Some things are brand new

Subnet renumbering Site-local and link-local addresses Address generation (auto-configuration) Anycast Duplicate address detection

Some things are likely to become more common End-to-end connectivity Multicast Use of clocks and timers (at Layer 3, not just TCP) Host multi-homing

Some things are just different Flows (QoS) Fragmentation ICMPv6 Subnet scanning attacks Packet filtering methods

For the most part, IPv6 is like IPv4, only more so


IPv6 Security:Infrastructure Protocols

DHCPv6 DNS Routing (OSPF) Mobility Send (SEcure Neighbor Discovery)


IPv6 Infrastructure Security: DHCPv6 Stateful alternative to auto-configuration (RFC 2642)

Typically triggered by RA More options

May be used statelessly (RFC 3736) together with RFC 2642 draft-ietf-dhc-stateless-dhcpv6-renumbering-00 identifies renumbering issues

Threat model Perimeter blocking, insider attacks Server impersonation (Reconfigure messages) Denial of Service (address exhaustion) Confidentiality is not considered important Key management, roaming, man-in-the-middle are problems Delayed authentication key management option

IPsec can be used between servers and relays e.g., with RFCs 3633, 3646, and fail over draft-ietf-dhc-relay-agent-ipsec-01 recommends ESP transport mode with NULL

encryption and preshared secrets Dual-stack operation has several open questions

Multiple responses, per interface or per node, DNS search paths and load balancing, inconsistent responses and options


IPv6 Infrastructure Security: DHCPv6 References:

RFC 3118 for DHCP authentication and replay detection RFC 3315 for DHCPv6 protocol RFC 3633 for prefix delegation RFC 3646 for recursive DNS configuration RFC 3736 for stateless DHCPv6 draft-ietf-dhc-auth-suboption-03 for server and relay use of HMAC draft-ietf-dhc-dhcpv6-ctep-opt-01 for configured tunnel end points draft-ietf-dhc-dhcpv6-opt-nisconfig-05 for NIS and NIS+ information draft-ietf-dhc-dhcpv6-opt-rboot-00 for TFTP and remote booting draft-ietf-dhc-dhcpv6-opt-sntp-00 for simple NTP draft-ietf-dhc-dual-stack-00 for dual stack issues draft-ietf-dhc-failover-12 for server redundancy


IPv6 Infrastructure Security: DNS Issues Most operational considerations with DNS are not security issues

Improper configuration and use with IPv6 can impact performance See draft-ietf-dnsop-ipv6-dns-issues-07

IPv6 has little impact on DNS Security (DNSSEC, TSIG) Some points to remember:

Local addresses should never be published Security models based on source address validation are weak and not

recommended Setting up an authorization mechanism (e.g., a shared secret, or public-

private keys) between a node and the DNS server has to be done manually and may require quite a bit of time and expertise.

Setting up the reverse tree is somewhat more complicated, but reverse DNS checks provide weak security at best

The only (questionable) security-related use for them may be in conjunction with other mechanisms when authenticating a user

Reverse chains for 6to4 addresses and Teredo addresses are impractical with Dynamic DNS Updates


IPv6 Infrastructure Security: Routing Example: OSPF for IPv6 (RFC 2740) Unchanged:

Fundamental mechanisms Flooding, DR election, area support, SPF calculations

Optional capabilities On-demand circuit support, NSSA areas, and multicast extensions

Most packets are not much larger than those in OSPF for IPv4 Changed:

Addressing semantics removed from packets and basic LSAs New LSAs carry IPv6 addresses and prefixes OSPF runs on a per-link basis, not on a per-IP-subnet basis Flooding scope for LSAs generalized Authentication removed from the OSPF protocol

Relies on IPv6s IPsec AH and ESP Most field- and packet-size limits in OSPF for IPv4 relaxed Option handling more flexible


IPv6 Infrastructure Security: Mobile IP Goals: roaming, address anonymity, location privacy Authenticated, dynamic registration (binding) is needed

Between the Mobile Node and the Home Agent Current draft specifies IPsec ESP and IKE (plus alternative) for:

Binding updates and binding acknowledgements Return routability messages: Home Test Init and Home Test ICMPv6 between the Home Agent and Mobile Node (e.g., prefix

discovery) User traffic (optional)

Need to work around lack of global PKI, IKE-IPsec overhead, ... See draft-ietf-mobileip-mipv6-ha-ipsec-06, draft-ietf-mobileip-

ipv6-24, and draft-ietf-mip6-precfgKbm-00 Firewalls need to control use of routing and home address headers


IPv6 Infrastructure Security: SEND (Secure Neighbor Discovery)

RFCs 2461 and 2462 define the Neighbor Discovery Protocol (NDP) including: Neighbor Discovery (ND) Router Discovery (RD) Address Autoconfiguration Address Resolution Neighbor Unreachability Detection (NUD) Duplicate Address Detection (DAD) Redirection

Nodes on the same link use NDP to discover each other, to determine link-layer addresses, to find routers, and to maintain reachability information. NDP is used both by hosts and routers Called for using IPsec AH to prevent address theft and spoofing Requires many manually configured security associations


IPv6 Infrastructure Security: SEND (Secure Neighbor Discovery)

SEND defines new NDP (ICMPv6) options to carry public-key-based signatures and a zero-configuration mechanism for showing address ownership Hash of public key used to generate address Routers are certified by X.509 certificates and a trust anchor Messages are signed Confidentiality is not provided Replay detection uses timestamps (multicast) or nonces (unicast)

Hard parts Discovering a routers certificate chain Operation in partially secured mode

Other issues Link layer attacks Denial of service All-Nodes Multicast Group and the Solicited-Node Multicast Group

subscription Attacks against the hash function (59 bits) and RSA (384 bit)


Need for Protocol Security

Successful protocol attacks are continual occurrences Packet sniffers, source address forgery Source routing hoaxes, fragmentation attacks, DNS and routing

protocol abuses TCP sequence number prediction and session hijacking Denial of service attacks on cryptographic protocols

Core network routing and DNS mishaps have occurred Authentication and integrity are increasingly important

Confidentiality (encryption) without strong integrity checks can be abused

Much of the open Internet infrastructure is public but vulnerable Unencrypted passwords are increasingly regarded as inadequate


Outline of Section 4: IPsec

Overview of IPsec Changes to AH and ESP New algorithms and transforms Updates to the architecture IPsec and the IPv6 infrastructure Other issues and considerations IKE design goals IKEv1 review Need for a re-design IKEv2 design choices IKEv2 key exchange Open issues, summary, and references


Overview of IPsec The idea of IPsec goes back to early 1990s (at least)

Hour glass model Lower layer protection is technology dependent Higher layer protection is application dependent

The only proper capitalization is IPsec IPsec has multiple components

Protect packets on the wire Provide protection based on a security policy Automate key management

IPsec works by applying, enforcing, and managing the use of Security Associations (SAs) that Define protection Help enforce security policy according to a processing model Are maintained by key management


Overview of IPsec: Scope

IPsec only does one part of security IPsec can provide:

Data origin authentication Connectionless integrity Confidentiality Replay detection Limited traffic flow confidentiality Plausible deniability Access control (i.e., packet filtering)

For any IPv4 or IPv6 datagram Provided


Protocol Security: IPsec provided we can trust identities and

implement IPsec correctly on a secure platform

IPsec provides an extraordinarily sound protocol security infrastructure, but details matter: Design was bottom up Implementing IPsec is difficult Interoperability is still an issue We have to figure out how to use it, case by case

See draft-bellovin-useipsec-03.txt

Changes in IPsec are still in the worksall parts


Limits of Protocol Security

IPsec does not help with system, software, storage, physical, or personnel security

If you think cryptography is the solution to your problem, you dont know what your problem is.

Roger Needham

The error of Applied Cryptography is that I didnt talk at all about the context. I talked about cryptography as if it were The Answer. I was pretty nave.

Bruce Schneier


IPsec Uses Protocol Encapsulation

Application Message: http, smtp, ftp, telnet, dns, ...

TCP Segment

IP Datagram

IEEE 802 or PPP Frame

Header

Header

Header Trailer

IPsec fits in here

End to end but also visible to intermediate systems (routers) The IP Datagram may begin with another IP Header (IP in IP)


Choice of Layers for Security Encapsulation

Higher layer security is more application dependent and technology independent.

End-to-end security is easier to provide at higher layers; link or point-to-point security at lower layers.

Higher layers are more likely implemented in software; lower layers in hardware.

Higher layer encryption cannot protect lower layer headers; lower layer encryption may have to trust intermediate nodes.

Middle layer standards are attractive if they can get the benefits of both ends.


Properties of IP-Layer Protection

Allows bulk protection for end-to-end connections or across untrusted network clouds Can be deployed at hosts or routers, e.g.:

VPNs Remote access to a trusted enclave Specific end-to-end connections between systems in different COIs

Implementation is possible in hardware or software In operating systems, network interface cards, crypto boxes,

Software is often operating system vendor dependent Can use encryption accelerators or bump in the wire boxes Attention to 32 and 64 bit alignment

Question of how to support upper layer requirements Choice of services, algorithms, keying, QoS User-based, process-based, or system-based access controls


IPsec Design Principles

Scale to global use Must include mechanized key management

Interoperable crypto: includes a required option RECOMMENDED or REQUIRED algorithms are

Sound Publicly disclosed and widely implemented Minimally encumbered by export restrictions and IPR Efficient (given the above properties)

Identity hiding, forward secrecy, DoS protection,


IPsec Overview Developed over the last 12 years

RECOMMENDED in IPv4 and REQUIRED in IPv6 RFCs 18251829 (1995) RFCs 24012412 (1998) Third version emerging now

Interoperable, high quality, cryptographically based security Cryptographic protection of datagrams:

Authentication Header (AH) and Encapsulating Security Payload (ESP) Algorithms for authentication, integrity, replay detection, and encryption

Negotiated crypto transforms; user-defined options Security Associations (SAs) and processing model:

Established and managed out of band Specify policy, management, and processing rules

Entity Authentication and Key Management support protocols Manual (mandatory) and mechanized


November 1998 IPsec RFCsMany of these RFCs will be revised in the next year (or so) 2401 Security Architecture for the Internet Protocol. S. Kent, R. Atkinson.

2402 IP Authentication Header. S. Kent, R. Atkinson.

2403 The Use of HMAC-MD5-96 within ESP and AH. C. Madson, R. Glenn.

2404 The Use of HMAC-SHA-1-96 within ESP and AH. C. Madson, R. Glenn.

2405 The ESP DES-CBC Cipher Algorithm With Explicit IV. C. Madson, N. Doraswamy.

2406 IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson.

2407 The Internet IP Security Domain of Interpretation for ISAKMP. D. Piper.

2408 Internet Security Association and Key Management Protocol (ISAKMP). D. Maughan, M. Schertler, M. Schneider, J. Turner.

2409 The Internet Key Exchange (IKE). D. Harkins, D. Carrel.

2410 The NULL Encryption Algorithm and Its Use With IPsec. R. Glenn, S. Kent.

2411 IP Security Document Roadmap. R. Thayer, N. Doraswamy, R. Glenn.

2412 The OAKLEY Key Determination Protocol. H. Orman. (Informational)


Other Relevant RFCsMany of these RFCs will be included in the revisions

1321 The MD5 Digest Algorithm (and 1810 Report on MD5 Performance) 1750 Randomness Recommendations for Security (revision in draft) 1828 IP Authentication using Keyed MD5 2094 Group Key Management Protocol (GKMP) (Experimental) 2104 HMAC: Keyed Hashing for Message Authentication (and RFC 2202, Test Cases) 2284 PPP Extensible Authentication Protocol (EAP) 2394 IP Payload Compression Protocol (IPComp) 2451 The ESP CBC-Mode Cipher Algorithms 2460 Internet Protocol, Version 6 (IPv6) Specification (and related RFCs) 3168 The Addition of Explicit Congestion Notification (ECN) to IP 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)

Profile 3456 Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture 3526 More Modular Exponential (MODP) Diffie-Hellman Groups for Internet Key Exchange (IKE) 3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec


IPsec Wire Protocols Authentication Header (AH)

Connectionless integrity Data origin authentication Replay detection

A form of partial sequence integrity based on a window algorithm Improper encapsulation

Encapsulating Security Payload (ESP) All AH services (above) Confidentiality Partial traffic flow confidentiality Proper encapsulation

Each has tunnel mode and transport mode Transport mode must be end to end (host to host),

Protects an upper layer protocol Applied above fragmentation

Tunnel mode has an outer IP header and inner IP header Protects inner IP datagram


IPv6 Header (Again)

Flow Label(20 Bit)

Traffic Class(8 Bit)

Version(4 Bit)

Payload Length(16 Bit)

Next Header(8 Bit)

Hop Limit(8 Bit)

Destination Address(128 Bit)

Source Address(128 Bit)

IPv4 protocol is IPv6 next header


IPsec: Authentication Header (AH) Format

Reserved(16 bits)

Payload Length(8 bits)

Next Header(8 bits)

Security Parameters Index (SPI)(32 bits)

Sequence Number Field(32 bits)

Authentication Data ICV, Integrity Check Value

(variable length, usually 96 bits)


ESP in IPv6 Transport Mode

BEFORE APPLYING ESP --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPLYING ESP --------------------------------------------------------- IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth| --------------------------------------------------------- || || * = if present, could be before ESP, after ESP, or both


IPsec: Encapsulating Security Payload (ESP) Packet Format

Security Parameters Index (SPI) (32 bits)

Sequence Number (32 bits)

Payload Data (variable)

Authentication Data (ICV, variable)

Padding (0-255 bytes)

Pad Length Next Header(8 bits)

Initialization Vector (optional, variable)

MIC(ICV)

Encrypt


IPsec Security Association (SA) A simplex connection that specifies an IPsec security protocol

AH or ESP, not both Typical bi-directional security requires (at least) two SAs

Contains all the needed parameters Selectors, algorithms, keys, replay counters, expiration time, mode

Selectors consist of a packet filtering 5-tuple Source applies security; destination verifies security Can be established by IKE or manual methods

Each IPsec entity maintains a Security Association Database (SAD) Indexed by a 3-tuple:

32-bit Security Parameter Index (SPI) chosen by the receiver IP Destination Address (only unicast is fully supported) Security protocol (AH or ESP)

Will become just SPI and IP Destination Address


IPsec Policy Enforcement At this point, the questions are:

Which incoming packets must have IPsec protection? What protection must be applied to an outgoing packet?

Independent of whether the necessary SAs exist or not

IPsec processing model includes a packet filtering firewall Security Policy Database (SPD) describes protection for each packet:

Pass through (no IPsec processing) Discard Apply IPsec (and how to do so)

Find one or more SAs exist in SAD or Invoke key management

Uses same selectors as SAD Specifies protocols, algorithms, and modes for IPsec processing

Unlike pure firewalls, processing model allows authentication and security information to be used in filtering decision


IPsec Processing Model

IKEAH/ESP

BLACK

Discard

Discard

IPsec boundary

RED


Major Changes to AH and ESP AH and ESP

Extended sequence numbers SA naming Better multicast support Separate RFC to specify MANDATORY algorithms

Just ESP Improved traffic flow confidentiality

Padding Protocol 59

Support for combined mode algorithms Confidentiality-only service is now a MAY,

not a MUST


Anti-Replay Sequence Numbers Transmitter always increments sequence number Receiver may choose to ignore it

If the receiver is not going to perform anti-replay check, receiver SHOULD tell transmitter to ignore sequence counter wrap-around

Done at SA establishment Implies a SAD flag

Extended sequence numbers (ESN) 64-bit instead of 32-bit counter Negotiated property of a SA High order 32 bits:

Stored by sender and receiver Not transmitted Included in ICV calculation

For ESP, after the next header; for AH, at the end Multi-sender SA anti-replay is not supported


SA Identification Unicast SAs:

SPI and destination address are sufficient Receiver may use protocol (AH/ESP) too: local decision

Multicast SAs: SHOULD support demuxing based on SPI,

destination address, and, optionally, source address SAD flags to cover unicast and multicast:

SPI only SPI + destination address SPI + source + destination addresses

What about protocol field in multicast case?


Traffic Flow Protection (ESP) Extended padding

New requirement to be able to add bytes after the end of the IP Payload, prior to the beginning of the Padding field.

Next Header New requirement to be able to generate and discard

dummy packets Protocol or Next Header = 59

Possible to make IPsec black side look like a constant rate stream of equally sized packets


Combined Mode Algorithms (ESP)

Added combined confidentiality mode algorithms. The description of the payload data model and ICV

are broadened and extended In the processing model

Inbound and Outbound packet processing now has two paths

(1) separate confidentiality and integrity algorithms, (2) combined confidentiality mode algorithms.

The encryption/decryption and integrity sections have been combined for both inbound and outbound packet processing


Algorithm Requirements For ESP and AH

See draft-ietf-ipsec-esp-ah-algorithms-01

ESP Encryption and Authentication Algorithms MUST NULL MUST- TripleDES-CBC [RFC 2451] SHOULD+ AES-CBC with 128-bit keys [RFC 3602] SHOULD AES-CTR [AES-CTR] SHOULD NOT DES-CBC [RFC 2405]

ESP Authentication Algorithms MUST HMAC-SHA1-96 [RFC 2404] MUST NULL SHOULD+ AES-XCBC-MAC-96 [RFC 3566]

ESP Combined Mode Expect [AES-CCM] to be specified in the future

AH Authentication Algorithms MUST HMAC-SHA1-96 [RFC 2404] SHOULD+ AES-XCBC-MAC-96 [RFC 3566] MAY HMAC-MD5-96 [RFC 2403]


Cryptographic Suites for IPsec See draft-ietf-ipsec-ui-suites-06

Intended to become a BCP Suite VPN-A (common use today)

ESP Encryption TripleDES in CBC mode [RFC2451] Integrity HMAC-SHA1-96 [RFC2404]

IKE, IKEv2, and Rekeying Encryption TripleDES in CBC mode [RFC2451] Pseudo-random function HMAC-SHA1 [RFC2404] Integrity HMAC-SHA1-96 [RFC2404] Diffie-Hellman group 1024-bit MODP [RFC2409]

Suite VPN-B (expected choice in the future) ESP

Encryption AES with 128-bit keys in CBC mode [AES-CBC] Integrity AES-XCBC-MAC-96 [AES-XCBC-MAC]

IKE, IKEv2, and Rekeying Encryption AES with 128-bit keys in CBC mode [AES-CBC] Pseudo-random function AES-XCBC-PRF-128 [AES-XCBC-PRF-128] Integrity AES-XCBC-MAC-96 [AES-XCBC-MAC] Diffie-Hellman group 2048-bit MODP [RFC3526]


Still Thorny Topics

Why AH?

PKI

NATs and firewalls

Mobility and Multi-Homing


New Algorithms and Transforms

The three major new items are AES: security and efficiency

Emerging as alternative to 3DES Multiple uses: confidentiality and integrity

Additional modes: mostly efficiency Counter mode Combined mode

New Mod p groups for IKE: security Other ciphers and longer hash functions

Not likely to have near-term impact Camilla SHA-256, SHA-384, SHA-512


AES: Advanced Encryption Standard

128-bit block cipher Re-key before 264 blocks (about Avogadros Number of bits!)

Repeated 4-step round function 10, 12, or 14 rounds according to key size

Key lengths of 128, 192, or 256 bits See:

http://www.nist.gov/aes http://www.esat.kuleuven.ac.be/~rijmen/rijndael/

Performance data at: http://www.counterpane.com/aes-performance.pdf http://csrc.nist.gov/encryption/aes/round1/r1-ansic.pdf http://www.tcs.hut.fi/~helger/aes/rijndael.html http://csrc.nist.gov/encryption/aes/round1/r1report.pdf


AES (Rijndael): Overview of Operation

128-bit states and keys are arranged in 4 x 4 arrays of bytes.

S0,0 S0,1 S0,2 S0,3

S1,0 S1,1 S1,2 S1,3

S2,0 S2,1 S2,2 S2,3

S3,0 S3,1 S3,2 S3,3

k0,0 k0,1 k0,2 k0,3

k1,0 k1,1 k1,2 k1,3

k2,0 k2,1 k2,2 k2,3

k3,0 k3,1 k3,2 k3,3


AES (Rijndael): Overview of Operation

Ten to 14 rounds Four basic operations in a round:

1. Substitute each state byte according to its value (one S-box: non-linear permutation of bytes)

2. For i = 0 to 3, shift row i circularly left by i bytes.3. Perform a fixed affine transformation on each

column (matrix multiplication and addition).4. XOR the state with the round key.


Modes of Operation

See NIST Pub. 800-38A: Dworkin, M., Recommendation for Block Cipher

Modes of Operation: Methods and Techniques, NIST Special Publication 800-38A, December 2001.

Five defined: ECB: electronic code book CBC: cipher block chaining CFB: cipher feedback OFB: output feedback CTR: counter


Five IPsec Standards for AES AES in CBC mode

RFC 3602, S. Frankel, R. Glenn, and S. Kelly, The AES-CBC Cipher Algorithm and Its Use with IPsec, September 2003.

AES in CTR mode RFC 3686, R. Housley, Using Advanced Encryption Standard (AES) Counter

Mode With IPsec Encapsulating Security Payload (ESP), January 2004. AES to create an ICV (extended CBC MAC)

RFC 3566, S. Frankel and H. Herbert, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec, September 2003.

AES in combined confidentiality and integrity mode (CCM) draft-ietf-ipsec-ciph-aes-ccm-05.txt, R. Housley, Using AES CCM Mode With

IPsec ESP, November 2003. AES as an IKE PRF (Pseudo-Random Function)

RFC 3664, P. Hoffman, The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE), January 2004.


Cipher Block Chaining Mode (CBC)

Key

Key

Key

+

+

C1

C2

C3

Decrypt

Decrypt

Decrypt

Key

Key

Key

+

+

P1

P2

P3

Encrypt

Encrypt

Encrypt

+

Initialization Vector(IV)

+ P1

P2

P3


AES in CBC Mode Unpredictable 128-bit explicit Initialization Vector (IV) in each packet

XOR IV with first block and then encipher Subsequently XOR each plaintext block with previous ciphertext and

then encipher Receiver deciphers and then XORs

128-bit keys MUST; 192 and 256 MAY 10, 12, 14 rounds, respectively

Must pad payload to multiple of 128 bits Including the Pad Length and Next Header

For use with IKE Phase 1: ID = 7 For use with ESP: ID = 12 May use SHA-1 or MD5 to generate 128-bit keys

Consider longer hashes for longer keys:http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf


Counter Mode (CTR)Counter modecan use fewerthan 128 bits.

Key Key

Key

Key

Encrypt

Encrypt

AESEncrypt

Key

Key

Encrypt

Encrypt

C 1+

P1

+

+

+

P1C 1 AES AES

P2

+

P2

EncryptAESC2 C2 AES

P3

+

P3AESC3 C3


CTR Mode (from RFC 3686)

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Initialization Vector || (8 octets) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |~ Encrypted Payload (variable) ~| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |~ Authentication Data (variable) ~| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1. ESP Payload Encrypted with AES-CTR

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Nonce |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Initialization Vector (IV) || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Block Counter |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2. Counter Block Format


CTR Mode Operation (RFC 3686)

Encipher:CTRBLK := NONCE || IV || ONE

FOR i := 1 to n-1 DO

CT[i] := PT[i] XOR AES(CTRBLK)CTRBLK := CTRBLK + 1

END

CT[n] := PT[n] XOR TRUNC(AES(CTRBLK))

Decipher:CTRBLK := NONCE || IV || ONE

FOR i := 1 to n-1 DO

PT[i] := CT[i] XOR AES(CTRBLK)CTRBLK := CTRBLK + 1

ENDPT[n] := CT[n] XOR TRUNC(AES(CTRBLK))


AES in Counter (CTR) Mode

Specified for ESP (transform 13), not for IKE Phase 1 Keys and rounds as in AES CBC Apply AES to 128-bit counter

32-bit nonce, generated one per SA (4 additional KEYMAT bytes) 64-bit explicit IV, one per packet 32-bit counter, one per block

Must NEVER use same key and counter twice Static keys not allowed Nonces differ in each direction

Deciphering = Enciphering = XOR with text No need to pad last block (except to 32-bit ESP boundary) Additional padding allowed

Allows parallel processing, pipelining, and pre-computation Tampering with unauthenticated ciphertext is trivial

MUST use ESP integrity (ICV) HMAC SHA-1 or HMAC MD5 suffice


AES for ICVs (XCBC MAC)

Uses 128-bit AES keys only Algorithm ID 9 with AH or ESP Idea is to run AES in CBC mode

E[i] = AESk(M[i] XOR E[i 1])

Pad the last block with 10* as needed Take the last enciphered block as the ICV

Actually, truncate it to 96 bits as done in HMAC Secure if all packets same length The fix for different lengths is to use three keys:

k1: used as k above k2: XOR with last block before last enciphering if no padding k3: XOR with last block before last enciphering if padding

See: http://www.cs.ucdavis.edu/~rogaway/papers/3k.ps http://csrc.nist.gov/encryption/modes/proposedmodes/xcbc-mac/xcbc-mac-

spec.pdf


AES in Combined Mode (CCM) Defined for ESP Combines CTR Mode encryption and generating an ICV

Uses only one key and one pass 128-bit keys MUST, 192 and 256 MAY 64-bit and 128-bit ICV MUST; 96 MAY

Same key reuse danger as pure CTR Mode Can extend ICV to cover SPI and Sequence Number

(or ESN) Counter similar to pure CTR Mode enciphering

1 byte CCM flags 3 bytes nonce 8 bytes explicit IV 4 bytes counter


Updates to Architecture (rfc2401bis)

Still under construction Additional, more flexible selectors Support for multiple SPDs per interface New processing flowchart

Added forwarding and routing lookup prior to SPD lookup, for more sophisticated VPN support

Included SPD cache and decorrelation rules Removed SA bundles

Added a Peer Authorization Database (PAD) Allow gateways to use transport mode


Traffic Selectors (SPD Entries) in rfc2401bis

Selectors based on the packet filtering 5-tuple Reconciled with IKEv2 selector capabilities

Lists of source and destination address ranges and protocol plus

Port ranges (UDP and TCP) ICMP Type / Code values or IPv6 Mobility Header (MH) Message Types

Support for multiple SAs between same two endpoints Named selectors (with additional management support)

RFC 822 address, e.g., [email protected] fully qualified DNS name, e.g., foo.example.com X.500 distinguished name

Wildcards and use of populate from packet If an SA needs to be set up, and the selector specifies a range

of addresses, should the SA be set up for one address or the entire range?


Processing Flowchart Changes SPDs no longer one per interface

Support as many as needed in a specific context e.g., per VPN

Forwarding decision separated from SPD selection SPD may be selected via packet header and local information

e.g., inbound interface Forwarding performed after IPsec processing

Nested SA support now optional SA bundles removed Needs coordination between forwarding tables and SPD entries


New Outbound Processing Model^

Unprotected Interface |+----------+

...................|Forwarding||SPD Selection|

+-------------+^

Protected Interface |


New Inbound Processing ModelUnprotected Interface |

V+-----+ IPsec protected

...................>|Demux|-------------------+: +-----+ |: | Not IPsec |: |-----------+ |: V | |: +-------+ V V

+-----+ +-------+ |Bypass/| +------+ +------+|SPD-O| |Discard||IKE| |: | | +---+ |: V | V: +----------+ +---------+:...............|Forwarding|


Peer Authorization Database (PAD)

Added a Peer Authorization Database (PAD) Used at the interface between IPsec and key

management Contains the range of names a peer is allowed to

represent when creating child SAs Contains authentication methods and other

authentication parameters for a peer Must be consulted to verify selectors received

from key management


IPsec and IPv6 Infrastructure

The big change in IPsec from IPv4 to IPv6 is that IPsec is MANDATORY in IPv6

IPv6 includes: ICMPv6 Auto-Configuration Discovery Addressing Modes

Multicast, Anycast


IPsec: IKE and ICMPv6 ICMPv6 can be end-to-end, any-to-end, or link local ICMPv6 can be Unicast, Multicast, or Anycast; IKE is Unicast IKE can only run if UDP is already enabled See draft-ietf-ipngwg-icmp-v3-04. Also, J. Arkko wrote this table:

Dest. Unreachable Any-to-End May use IKE Packet Too Big Any-to-End May use IKE Time Exceeded Any-to-End May use IKE Parameter ProblemEnd-to-End May use IKE Echo Request End-to-End May use IKE Echo Reply End-to-End May use IKE Redirect Link Local May use IKE Router Solicit Link Local Must Not use IKE Router Advert. Link Local Must Not use IKE Neighbor Solicit Link Local Must Not use IKE Neighbor Advert. Link Local Must Not use IKE Router Renumb. End-to-End May use IKE


IPsec for ICMPv6: Manual Keying and Neighbor Discovery

Neighbor discovery uses many destination address types ICMPv6 message types overloaded Destination may be Multicast (M), Unicast (U), or Anycast (A)

1 Router and Prefix Discovery 133->M; 134->MU2 Address Auto-Configuration 135->MUA; 136->MU3 Duplicate Address Detection 135->MUA; 136->MU4 Address Resolution 135->MUA; 136->MU5 Neighbor Reachability Detection 135->MUA; 136->MU6 Redirect 137->U

Attacks and consequences vary case by case Need Security Associations for:

Each nodes Unicast and solicited node Multicast addresses Known ahead of time (not RFC 3041 addresses)

The All Nodes and All Routers Multicast addresses


Other Issues and Considerations Multicast

Issues with key distribution and replay detection NAT traversal

Typically run ESP (transport or tunnel mode) over UDP See draft-ietf-ipsec-udp-encaps-09.txt

SCTP Need to use the same SA across many addresses

APIs and Channel Bindings API (PF_KEY) exists between IKE and IPsec No common, satisfactory way for applications to specify, verify, or discover IPsec

protection A proposal to use channel bindings was presented at IETF 58

ECN Propagate from outer to inner header at tunnel mode terminating endpoint

Multi-Homing and Mobility Need to move a SA from one address to another


IKE Design Goals Manage creation and deletion of security

associations Negotiation, lifetimes, sensitivity levels, algorithms,

notifications Flexible policy and usage Sound protocol design Support public and private use Support different algorithms and mechanisms Integrate entity authentication with key exchange Guard against active attacks and some denial of

service attacks Simplicity was not a design goal


Hierarchical Key Management Long term keys

Often public key and private key pairs (PKI) Public components contained in certificates Bind names to keys according to some policy May belong to hosts, persons, etc.

May be shared secret keys Usual lifetime is months to a few years

Short term keys Usually secret key components (e.g., AES or HMAC keys) Unilaterally or cooperatively generated Agreement usually coupled with authentication

Based on the long-term keys May belong to a TCP connection, e-mail message, VPN, etc.

Usual lifetime is a few minutes to a few days


Main Tool: Diffie-Hellman Key Exchange

Known toAlice

Known toBobPublic

A Bp, g

gA mod p

gB mod p

gB mod p

gA mod p

(gB)A mod p

= gAB mod p

(gA)B mod p

= gAB mod p

gA mod p

gB mod p

Choose secretvalues A, B

Compute andexchange public

values gA, gB

Compute sharedsecret gAB


Ephemeral Diffie-Hellman

Alice and Bob pick random secrets Aand B, and they generate gAB

Play-in-the-middle attack Problem is lack of authentication

Authentication and key exchange have to be tightly connected

Also need to prevent replays and other active attacks


IKEv1 Compromise composed from several alternatives

Design was based on Photuris, SKEME, ISAKMP, and Oakley Main RFCs are 2407, 2408, 2409, and 2412

Authentication Two way Based on public key certificates or pre-shared secrets

Session-key or SA-key agreement SA setup and maintenance Additional features

Identity hiding Forward secrecy Negotiation Rekeying

Support added for NAT traversal, Legacy authentication DHCP


IKEv1 Combines 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

Performs authentication with Signatures Public key encryption

Two versions Based on ability to decrypt, extract a nonce, and compute a hash

Pre-shared keys Adopts four of the five Oakley Diffie-Hellman groups Shows how to compute specific keying material


IKEv1 Mechanisms

MUST Pre-shared keys DES-CBC with weak key check (in standard, but actually deprecated) MD5 and SHA-1 HMAC mod p Diffie-Hellman (Group #1)

SHOULD 3DES (Strongly Encouraged) Tiger (hash) DSS RSA signatures and encryption mod p Diffie-Hellman (Group #2)

MAY Elliptic curve Diffie-Hellman over char 2 and large prime fields User defined


The Oakley Key Determination Protocol

Provides keying material for encryption, hashing, and authentication Extends ideas from Photuris

Cookies Perfect forward secrecy

Diffie-Hellman with standard or user-defined groups (including elliptic curves) Identity hiding

Compatible with ISAKMP SA management and manual KD For long-term keys

Manual keying and DNS security required PGP, X.509 (pkix), DSS optional

Privacy and perfect forward secrecy Main Mode Optimized version without privacy Aggressive Mode Efficient re-keying with a hash function Quick Mode


ISAKMP/Oakley/IKE/SKEME Features

Cryptographic key management procedures and protocols Both manual and automatic distribution of keys Specific public-key based approaches defined Other methods may be used

Uses PKI or pre-placed keys Two-way authentication Negotiation of services and algorithms Privacy of parties identities Perfect forward secrecy Limited protection against denial of service Negotiation of compression Label-based access controls


ISAKMP Messages Header

Initiator cookie Responder cookie Version, type, flags Message ID Start chain of payloads

Contain ordered list of payload types, filled in during exchanges Security Association Proposal Transform Notification Key Exchange Identification Certificate Hash Signature Nonce Delete Private Use

For negotiation: An SA contains Proposals, which contain Transforms


ISAKMP Notification Types

Error Value Error Value INVALID-PAYLOAD-TYPE 1 INVALID-KEY-INFORMATION 17 DOI-NOT-SUPPORTED 2 INVALID-ID-INFORMATION 18 SITUATION-NOT-SUPPORTED 3 INVALID-CERT-ENCODING 19 INVALID-COOKIE 4 INVALID-CERTIFICATE 20 INVALID-MAJOR-VERSION 5 CERT-TYPE-UNSUPPORTED 21 INVALID-MINOR-VERSION 6 INVALID-CERT-AUTHORITY 22 INVALID-EXCHANGE-TYPE 7 INVALID-HASH-INFORMATION 23 INVALID-FLAGS 8 AUTHENTICATION-FAILED 24 INVALID-MESSAGE-ID 9 INVALID-SIGNATURE 25 INVALID-PROTOCOL-ID 10 ADDRESS-NOTIFICATION 26 INVALID-SPI 11 NOTIFY-SA-LIFETIME 27 INVALID-TRANSFORM-ID 12 CERTIFICATE-UNAVAILABLE 28 ATTRIBUTES-NOT-SUPPORTED 13 UNSUPPORTED-EXCHANGE-TYPE 29 NO-PROPOSAL-CHOSEN 14 UNEQUAL-PAYLOAD-LENGTHS 30 BAD-PROPOSAL-SYNTAX 15 RESERVED (Future Use) 31 - 8191 PAYLOAD-MALFORMED 16 Private Use 8192 - 16383

Status Value Status Value CONNECTED 16384 RESERVED (Future Use) 16385 - 24575 Private Use 32768 - 40959 DOI-specific codes 24576 - 32767 RESERVED (Future Use) 40960 - 65535


Phase 1 Authentication with PK Encryption: Type 1

Initiator Responder

Main mode HDR, SA --> HDR, KE,PubKey_i, HDR, SA, KE, PubKey_i,


Main Issues with IKE v1

Efficiency and Complexity Security and Correctness Robustness Interoperability versus Flexibility Documentation


Issues with IKE v1: Efficiency Remove the DOI, SIT, Labeled Domain

Identifier fields, and the Commit and Authentication Only bits

Decrease latency in the common case by making the initial exchange 2 round trips (4 messages), and allowing piggybacking setup of a CHILD_SA in 2 messages instead of 3


Issues with IKE v1: Security and Correctness

Replace the cryptographic syntax for protecting the IKE messages themselves with one based closely on ESP to simplify implementation and security analysis

Fix bugs such as the hash problem Documented in draft-ietf-ipsec-ike-hash-revised-02

(expired) Publish a security proof for the protocol

See Crypto 2002 (Canetti and Krawczyk)


Issues with IKE v1: Robustness Reduce the number of possible error states by making

the protocol reliable (all messages are acknowledged) and sequenced

Allow the responder not to do significant processing until it receives a message proving that the initiator can receive messages at its claimed IP address, and not commit any state to an exchange until the initiator can be cryptographically authenticated

Specify Traffic Selectors in their own payload type rather than overloading ID payloads

Specify required behavior under error conditions or when data are received and not understood

Simplify and clarify how shared state is maintained in the case of network failures and DoS attacks


Issues with IKE v1: Interoperability versus Flexibility

Replace eight different initial exchanges with a single four-message exchange (and limit changes in authentication mechanisms to a single AUTH payload rather than restructuring the entire exchange)

Make specified Traffic Selectors more flexible Simplify making future revisions backwards

compatible Incorporate ideas from RFC 3715 to allow IKE

to negotiate through NAT gateways


Issues with IKE v1: Documentation

Define the IKE protocol in a single document and include NAT traversal, extended authentication, and remote address acquisition

Maintain existing syntax and magic numbers to the extent possible to make it likely that implementations of IKEv1 can be enhanced to support IKEv2 with minimum effort


IKEv2 Design Choices Phases and message counts Forward secrecy and computational efficiency Identity hiding Denial of service protection NAT Legacy authentication DHCP Mandatory algorithms


Phases and Message Counts All messages sequenced into request-response pairs IKEv2 starts with a four-message exchange (two round trips):

Algorithms negotiated long discussion of suites versus a la carte

Both parties authenticated Session key agreed upon IKE SA established One IPsec SA created

Reasons for more than 4 initial messages DoS protection Legacy authentication Incompatible Diffie-Hellman groups

Subsequent exchanges send notifications or set up additional IPsec SAs May have different security requirements, QoS, users, etc.

All messages after the first round trip have confidentiality and integrity In an ESP-like format


Forward Secrecy and Computational Efficiency

All keying material for IKE, AH, and ESP is derived just from the Diffie-Hellman value The signatures and MACs in messages 3 & 4

Authenticate the parties, Bind the keying material to the identities proved in this run of the

protocol Protect the protocol from active attacks

Forward secrecy means that if either partys long-term secret (signing key) is compromise, old traffic is unaffected

May reuse Diffie-Hellman values with new nonces Tradeoff between computation and forward secrecy


Identity Hiding

Identity Hiding Possible to hide actual identities from all

passive eavesdroppers Not IP or lower layer addresses, of course

Impossible to hide actual identities from all active attacks

Chose to protect the responder


Denial of Service Protection Idea:

Prove that a two-way conversation exists before committing resources

Method: Receive a message, put in a cookie that:

Can be authenticated later without storing anything Depends on the sender, message sent, and a local secret Cannot be forged by the attacker

Sender returns the original message plus the cookie Required in Photuris; optional in Oakley Chose to make this optional

Requires an extra round trip Showstopper for requiring this is UDP fragmentation attack


NAT Traversal IssuesIKEv2 adopted the methods added after IKEv1

appeared: IKE specifies source and destination ports as 500 Some NAPTs demux on SPIs and IKE cookies NAT detection works by echoing addresses in a

notify payload Once IKE detects NAT

Changes to port 4500 for IKE messages Same port as ESP encapsulation Adds a 32-bit zero word to distinguish IKE messages

Negotiates UDP encapsulation Sends the original addresses to build TCP checksums later Host not behind NAT must eventually remove the SA

See draft-ietf-ipsec-nat-t-ike-08


Legacy Authentication

Accommodate human and token card authentication for remote access by Alice

IKEv2 chose The EAP protocol (RFC 2284). Alice reveals her identity in message 3 and leaves out the

AUTH payload Bob authenticates with a public-key-based signature and

specifies the legacy authentication method e.g., MD5 challenge-response, OTP, or token card

Alice replies or asks for alternatives May be extra round trips Bob sets up the Child-SA or terminates

Important to avoid server impersonation or M-I-T-M attacks MUST NOT use the same method in IKE and unprotected

settings.


Address Acquisition and DHCP

Also used often for remote access Two proposals:

MODECFG a field in the IKE exchange in which the responder tells the

initiator an IP address DHCP-relay

running DHCP over IKE or over an ESP connection set up specifically for this purpose

MODECFG was chosen Simplicity and efficiency over generality and elegance


IKEv2 Mandatory Algorithms See draft-ietf-ipsec-ikev2-algorithms-05 Encrypted Payload Algorithms

MUST Confidentiality 3DES-CBC SHOULD+ Confidentiality AES-128-CBC MUST Integrity HMAC-SHA1

Diffie-Hellman Groups MUST 1024 MODP Group [RFC2409] SHOULD 1536 MODP Group [RFC3526] SHOULD+ 2048 MODP Group [RFC3526]

IKEv2 Transform Type 1 Algorithms (encryption) MUST ENCR_3DES [RFC2451] MAY ENCR_NULL [RFC2410] SHOULD+ ENCR_AES_CBC [AES-CBC] SHOULD ENCR_AES_CTR [AES-CTR]

IKEv2 Transform Type 2 Algorithms (pseudo-random function) MAY PRF_HMAC_MD5 [RFC2104] MUST PRF_HMAC_SHA1 [RFC2104] SHOULD+ PRF_AES128_CBC [AESPRF]

IKEv2 Transform Type 3 Algorithms (integrity) MAY AUTH_HMAC_MD5_96 [RFC2403] MUST AUTH_HMAC_SHA1_96 [RFC2404] SHOULD+ AUTH_AES_XCBC_96 [AES-MAC]


IKEv2 Payload Types No Next Payload 0 RESERVED 1-32 Security Association SA 33 Key Exchange KE 34 Identification - Initiator IDi 35 Identification - Responder IDr 36 Certificate CERT 37 Certificate Request CERTREQ 38 Authentication AUTH 39 Nonce Ni, Nr 40 Notify N 41 Delete D 42 Vendor ID V 43 Traffic Selector - Initiator TSi 44 Traffic Selector - Responder TSr 45 Encrypted E 46 Configuration CP 47 Extended Authentication EAP 48 RESERVED 49-127 PRIVATE USE 128-255

Note: Every payload contains a critical flagSome payloads hierarchically include othersThe SA payload describes proposals, algorithms, and attributes


IPsec: IKEv2 Key Exchange ProtocolIKEv2 adds nonces, directional protection, etc.

A BNA , gx

NB , gy

{ A, SIGA(gy, gx) MACKm (A) }Ke

{ B, SIGB(gx, gy) MACKm (B) }Ke


Initial IKEv2 Exchange Initiator (i) Responder (r) ----------- -----------

HDR, SAi1, KEi, Ni -->


IKEv2 Notify Message Types NOTIFY MESSAGES - ERROR TYPES Value NOTIFY MESSAGES - STATUS TYPES Value------------------------------ ----- ----------------------------- -----UNSUPPORTED_CRITICAL_PAYLOAD 1 INITIAL_CONTACT 16384INVALID_IKE_SPI 4 SET_WINDOW_SIZE 16385INVALID_MAJOR_VERSION 5 ADDITIONAL_TS_POSSIBLE 16386INVALID_SYNTAX 7 IPCOMP_SUPPORTED 16387INVALID_MESSAGE_ID 9 NAT_DETECTION_SOURCE_IP 16388INVALID_SPI 11 NAT_DETECTION_DESTINATION_IP 16389NO_PROPOSAL_CHOSEN 14 COOKIE 16390INVALID_KE_PAYLOAD 17 USE_TRANSPORT_MODE 16391AUTHENTICATION_FAILED 24 HTTP_CERT_LOOKUP_SUPPORTED 16392SINGLE_PAIR_REQUIRED 34 REKEY_SA 16393NO_ADDITIONAL_SAS 35 RESERVED 16394 - 40959INTERNAL_ADDRESS_FAILURE 36 Private Use 40960 - 65535FAILED_CP_REQUIRED 37TS_UNACCEPTABLE 38INVALID_SELECTORS 39RESERVED TO IANA 39 - 8191Private Use 8192 - 16383


AES as the IKE PRF

RFC 3664 The AES-XCBC-PRF-128 Algorithm for the

Internet Key Exchange Protocol (IKE) Similar to XCBC MAC but need more than 96

bits Skip the truncation step from 128 to 96 bits


New Mod p Groups

RFC 2409 (IKE) defined four groups:Group Size Method IKE Status IKEv2 Status# 1 768-bit mod p MUST# 2 1024-bit mod p SHOULD MUST# 3 155-bit EC F2155 SHOULD# 4 185-bit EC F2185 SHOULD

Larger groups may be needed to correspond to longer AES keys. RFC 3526 (More mod p Groups) added:

# 5 1536-bit mod p * SHOULD# 14 2048-bit mod p SHOULD+# 15 3072-bit mod p# 16 4096-bit mod p# 17 6144-bit mod p# 18 8192-bit mod p

* Group 5 was in widespread use before being documented in RFC 3526.


Open IssuesWork in Progress

PKI Mobility and Multi-Homing

Want SAs to persist across address changes

Identifiers and Locators HIP (Host Identity Protocol)


IPsec(v3) and IKEv2 Summary

Original flavor maintained Many small improvements

Security, documentation, usability AES, counter mode, combined modes Larger Diffie-Hellman groups Extended sequence numbers Traffic flow confidentiality IKEv2 is a great improvement in many ways Work still needed on PKI, mobility, IPv6, API


References Lots available for existing IPsec

See the book by Sheila Frankel, Demystifying the IPsec Puzzle For open source implementations

www.openbsd.org www.freeswan.org www.kame.net

Not much yet on recent changes IPsec WGs page at the IETF site

http://www.ietf.org/html.charters/ipsec-charter.html The AH (rfc2402bis), ESP, and IKEv2 drafts contain lists of changes The Architecture draft (-02) does not

For IKEv2 protocol security, see http://www.ee.technion.ac.il/~hugo/sigma.html http://www1.cs.columbia.edu/~angelos/Talks/IPsecTutorial/


Firewalls for IPv6: Role of Firewalls Firewalls solve different problems from IPsec

Enforce uniform policy at perimeter Stop outsiders from performing dangerous operations Provide a choke point and scalable, centralized control

End-to-end connectivity, tunneling, and encryption may conflict with this policy Traffic that cannot be checked at the firewall can bring

unpleasant things to your desktop IPsec is like SSL, only more powerful in this respect

The tunneling problem has no satisfactory solution Well run it on Port 80, so it gets through the firewall IPv6 transition mechanisms use various tunneling stacks


Firewalls for IPv6: Changing the Model

The perimeter security model is changing Clear boundaries do not exist Users are being forced to run safe(r) computers

Passwords on start up and wake up Virus protection Personal firewalls SSL, IPsec VPNs, PGP, encrypted hard drives, WiFi security Patches and updates

Firewalls themselves are changing too Location

Network or end system (personal firewall) Control

Administrator or end user


IPv6 Firewalls: Packet Filtering Packet filtering uses rules based on:

Source and destination addresses Protocol Source and destination ports Other fields like Traffic Class or Flow Label

Source and destination addresses are the easiest part, but IPv6 hosts typically have many addresses IPv6 sub-networks can be renumbered Some IPv6 addresses have restricted scope

IPv6 makes it harder to apply RFC 2827 consistently To prevent denial of service attacks with spoofed source addresses Especially with RFC 3041 addresses


IPv6 Firewalls: Extension Headers Processing IPv6 extension headers is more work

Routing and fragmentation headers may trigger an access decision

May get stuck on an unknown extension header Should a firewall send an unrecognized header ICMP? discard the packet? Note that the RFCs are unclear on firewall or middlebox

actions

Unknown destination options are a bit easier to handle

TLV format Still need to define policy for unknown types


IPv6 Firewalls: RH and HA Processing Many IPv4 firewalls prohibit source routing IPv6 Routing Header (RH) and Home Address (HA) rewrite addresses

Needed for mobile IPv6, TE, and multi-homing Want to recognize legitimate MobileIP addresses and route optimizations

RH and HA can turn any host behind a firewall into a router May enable an unauthorized Web server May break denial of service protections

What does this mean? Want to characterize what RH and HA are doing

Mobile IP: allow only one RH segment left, only if policy and use correspond

Demand secure Binding Updates or an authenticated packet before accepting HA

TE: decide which routers are configured to handle TE

Internet defined in the RFCs Internet accessed by enterprises


IPv6 Firewalls: Fragmentation

Some IPv4 firewalls prohibit fragmentation Extension headers make it harder to

determine whether the upper layer protocol number is in a fragment Cisco FRAGMENT keyword matches all non-

initial segments and initial segments if the upper layer cannot be determined


IPv6 Firewalls: ICMPv6 issues

ICMPv6 needs additional attention CISCO ACLs by default allow Neighbor

Discovery, Neighbor Advertisement, and Neighbor Solicitation but deny others

Hop count 255 may be defeated by tunneling

Is a reasonable policy-based approach to Redirects possible? Note the increased use of host multi-homing


IPv6 Firewalls: IPsec ESP

No reasonable solution to accessing encrypted content at the border exists The ipsec WG rejected an ESP-like transform

that left the upper layer header in the clear Another attempt is in the works

A proposal to use the Flow Label bits has other drawbacks

Consider using host-based, administratively controlled firewalls


IPv6 Firewalls: Peer-to-Peer Services

IPv6 without NAT makes peer to peer potentially more usable

Firewalls usually take an outbound onlystance, except for well-known servers

Possible approaches: Reserved range of high-numbered ports End-system firewalling IETF midcom WGs pinholing


Security and IPv6 Transition Two original IPv6 goals were

Security Transition

Secure transition only recently received attention

Main transition components Dual stack Tunneling Translation

Many variations Security issues similar Some differences in the details


Transition Strategies Various encapsulation (tunneling) proposals

SIT 6over4 (RFC 2529) 6to4 (RFC 3056) ISATAP Teredo (UDP port 3544)

Dual Stack Transition Strategy Main security issues:

Do not mistakenly configure a back door around firewall (e.g., tunneling) Make sure VPN policy is not violated Do not let the IPv6 network open attacks on the IPv4 network

After decapsulating, enforce address-interface consistency (anti-spoofing) and firewall rules

Requires careful configuration Do not provide a hiding place for DoS attacks

Including broadcast and reflection varieties Do not violate address legitimacy assumptions

e.g., ingress filtering, use of special addresses, broadcast, multicast


v6 Encapsulated in v4

Resolves Tunneling

IPv6 Transition Strategy

v6 encapsulatedin v4

v4 Firewall

Edge of Network

Bypasses v6 Firewall

v6

v6 Firewall

If v6 encapsulated in v4 encapsulated

in v4

IPv6

IPv4

DualStack


General Tunneling Security Issues Typically, a loose approach is taken to IPv6 service piloting Tunneling can break the perimeter defense

Automatic tunneling accepts packets from everywhere Consider some access control or firewall functionality For example, treat addresses the way stateful UDP filtering

works Tunnel exit should decrement hop count

Ambiguities exist with IPv4-mapped IPv6 addresses Applies to RFC 2373 ::ffff:a.b.c.d addresses in general

Some IPv6 pieces are only partially deployed or immature DNS, routing, applications

Enabling IPv6 may open routers to bugs, inefficiencies, or instabilities

IPsec can be deployed between routers and relay routers With manual keying or with IKE


Some IPv6 Security ToolsThanks to Gene Cronk

NMAP (http://www.insecure.org) open source port scanner with limited (TCP SYN) support HalfScan6 (http://www.habets.pp.se/synscan/programs.php?prog=halfscan6) open source

port scanner Strobe (http://www.tuxfinder.com/packages/?defaultname=strobe&nodesc=1) open source

port scanner Snort (http://www.snort.org) open source IDS with limited IPv6 support ISS RealSecure 7.0 and Proventia (http://www.iss.net) commercial IDS with IPv6 support NFR Sentivist 4.0 (http://www.nfr.com) commercial IDS with IPv6 support Ethereal (http://www.ethereal.com) open source packet sniffer with full IPv6 support NetCat6 (http://netcat6.sourceforge.net) simple Unix utility that reads and writes data across

IPv6 or IPv4 network connections designed to be a reliable "back-end" tool mPing (http://www.cdt.luth.se/~nord/progs/mPing) multicast monitoring tool; IPv6 support TCPDump (http://www.tcpdump.org) open source program that dumps traffic on a network

with full IPv6 support (Several other programs [COTS and F/OSS] with IPv6 support that have roughly the same functionality, including Solaris Snoop, COLD, Analyzer, WinDump, WinPCAP, NetPeek, and SnifferPro.)

SendIP (http://www.earth.li/projectpurple/progs/sendip.html) open source command line tool for sending arbitrary IP packets with full IPv6 support


IPv6 Security: Summary The IETF is still working on IPv6 security for ICMPv6,

IPv6 firewalls, mobility, transition, etc. Hackers, today, are turning on stealth IPv6 networks

after intrusions Increased use of IPsec depends in part on PKI and

user authentication The standard bag of tricks for IPv6 firewalls has not

been invented yet Security analysis must be a part of any service

providers or enterprises IPv6 transition plan The Internet defined by the IETF does not always

match the Internet deployed and used by todays enterprises

Documents

IPv6 Security Workshop - usipv6.com€¦ · – RFC 3633 for prefix delegation ... • Reverse chains for 6to4 addresses and Teredo addresses are ... IPv6 Security Workshop 27June