ICOS BOF Securing Internet Configuration Bernard Aboba Microsoft IETF 62, Minneapolis, MN

Outline What is IP Configuration? Problem definition Architectural Principles Potential approaches Provisioning

What is IP Configuration? Parameters IP address configuration (IP address, subnet mask) Default gateway configuration Internet layer parameter configuration (MTU, etc.) Name server configuration (IEN 116, DNS, WINS, iSNS, NIS) Boot configuration (TFTP, NFS, iSCSI) Service Location/Directory configuration (RLS, SLPv2, LDAP) Mobility configuration (MIP) Time server configuration (NTP, SNTP) Scenarios Intra-domain: Hosts that only obtain configuration within a single administrative domain Inter-domain: Mobile hosts moving between administrative domains (corpnet, home, carrier/ISP)

Security Problems Secure IP configuration Definition: secure configuration of IP address & configuration parameters Example: Secure configuration of the TFTP server Not a substitute for protocol security Does not preclude insecure use of a securely configured server Secure protocols Definition: Security for the protocols whose servers are configured Example: Secure TFTP Not a substitute for configuration security Assume mutual authentication/integrity/replay protection Enables continued operation if at least one good server can be discovered Client can detect/blacklist rogue servers Issues  Attacker can DoS configuration servers, so that only bogus configuration gets through  Not all protocols are secured, so blacklist not always possible Applications with major security problems Remote boot (boot server, boot image) Mobility (BU security)

Threat Model Documents RFC 3756, “IPv6 Neighbor Discovery (ND) Trust Models and Threats”, May 2004 RFC 3118, “Authentication for DHCP Messages” draft-ietf-dhc-v4-threat-analysis-02.txt, “Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis”, April 2004 draft-prigent-dhcpv6-threats-00.txt, “DHCPv6 Threats”, March 2001 Threats Rogue configuration servers (man-in-the-middle, DoS) Redirect attacks (e.g. rogue default gateway, DNS server) DoS attack via invalid configuration Accidentally configured configuration servers Rogue clients (DoS) Impersonation of another client Resource exhaustion attack on server (more likely on IPv4) CPU exhaustion (if heavyweight computation required) Non-threats Disclosure MAC, IP addresses are public information Most server addresses considered public information Not clear what, if any configuration data is sensitive

Required Security Services Data origin authentication and integrity/replay protection of IP address assignment & configuration parameters Protection of clients against rogue servers Protection of servers against rogue clients DoS protection Efficient request limiting (implementation issue) Lightweight anti-spoofing (e.g. cookies)

Architectural Principles Less is more Lower layer independence Higher layer independence Security at the Internet layer Algorithm support Mobility Support

Less is More The number of Internet layer configuration (security) mechanisms should be minimized and the chosen mechanisms should be as simple as possible. Need to support embedded hosts with limited resources Proliferation of configuration (security) mechanisms compromises interoperability, increases footprint and configuration latency Potential for conflict and additional traffic With multiple mechanisms, may need to try several and/or merge returned configuration

Lower Layer Independence Desirable for hosts to be able to configure themselves on multiple networks without adding configuration code specific to a new link layer. Multi-homed hosts becoming popular Examples: WWAN/WLAN phones Counter-examples RFC 903 (RARP) RFC 1661 (PPP IPCPv4) Assigns IP addresses instead of using BOOTP/DHC P NAS devices did not act as BOOTP/DHCP servers at the time (now common) IPv6CP (RFC 2472) only assigns link identifier, not prefix RFC 1877 (IPCPv4 Extensions for Name Service Configuration) PPPEXT WG has resisted equivalent IPv6CP extensions IPCP allocation no longer FCFS, requires IETF Consensus (RFC 3818) DHCPINFORM can be implemented over PPP instead IKEv2 CFG_REQUEST/REPLY (Section 2.19, 3.15) Allows IKEv2 peer to request configuration from its peer Support for configuration of IPv4/IPv6 address, netmask, prefix, DHCPv4/v6 server, DNS server, WINS server, routes  WINS not even defined for IPv6! Need to avoid chicken/egg problem (need inner address to configure tunnel mode SA, but can’t obtain inner address without a tunnel mode SA) Alternative mechanism still needed for other configuration parameters Alternative is multi-stage setup, snopping of IP address configuration by VPN server (RFC 3456)

Higher Layer Independence Internet Layer Configuration should avoid higher layer dependencies. Circular dependencies Higher layer operation depends on Internet layer configuration (addressing, fragmentation) Without an IP address, can't set up a TCP/SCTP connection Can't use higher layer protocols depending on reliable transport Resource issues Embedded hosts may wish to minimize boot ROM code Some boot ROMs support IP/UDP, but not TCP/SCTP Embedded systems may not have headroom for complex higher layer protocols (e.g. LDAP) Food for thought Certificate processing requires a footprint of the same order (or greater) than TCP.

Internet Layer Reliance If both lower and higher layer dependencies are undesirable, then IP configuration (security) needs to depend on the Internet layer. During boot, some Internet layer facilities may not be available IP fragmentation and reassembly not reliable when sending from the unspecified address IPsec requires an IP address Implications IPsec typically used only after address assignment or for relay- server security Payloads no larger than MTU; may need to build-in fragmentation support to handle certificate payloads

Algorithm Support In order to enable interoperability, it is necessary to define at least one mandatory-to- implement algorithm Algorithm support should be negotiable

EAP Extensible Authentication Protocol (EAP) is a media-independent framework for network access authentication RFC 3748 defines EAP over PPP IEEE 802.1X defines EAP over IEEE 802 wired networks IEEE i defines EAP over IEEE EAP encapsulation not defined on other link layers Defining EAP on a new link not just a protocol design exercise Standards organization defining the link layer must agree to the EAP security model (new state machine) Example: Would ANSI T.10 define EAP over Fibre Channel? Result: EAP introduces link layer dependency unless it can be run over IP (or higher) layers Algorithm support RFC 3748 mandatory-to-implement algorithm is MD5 Where this is inadequate, application needs to define its own mandatory-to-implement algorithm

Mobility Support Mobility is an important feature of the Internet Architecture and needs to be supported by Internet Layer Configuration (security) mechanisms Need for both intra and inter-domain support Need to be able to obtain (secure) configuration within administrative domains not previously visited or explicitly configured Transition issues Mix of security-capable/incapable clients and servers likely to persist for a long time Security capabilities and policies likely to vary between administrative domains

Potential Approaches Server-side Pre-shared keys Typically only used with mutual authentication Certificates Used to sign messages sent from client to server Requires provisioning of trust anchor on the client Client-side Nothing: client authentication not always important Same as before: client proves that it is the same client as in a previous transaction Resource ownership: client proves authorization for a resource (e.g. SEND) Client authentication to the server (e.g. EAP)

Provisioning Issues Initial provisioning: how does a customer obtain X hosts provisioned to obtain configuration securely? Re-provisioning: how do we deal with credential expiry, change or revocation?

Initial Provisioning Scenario: Company Y calls OEM, says “please send me 10K hosts, pre-provisioned for IP configuration security.” Can they easily be manufactured? Where goal is secure boot, credentials may need to be provisioned in NVRAM How many different credentials are required? Shared secrets, certificates, trust anchors, etc. How much boot ROM code is required? Certificate handling requires substantial footprint Boot ROM code often runs in REAL mode Does NVRAM need to be individually provisioned? Unique shared secret/certificate for each client? Same set of trust anchors?

Feedback?