1 / 18

ICOS BOF

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

stephanie-carpenter
Télécharger la présentation

ICOS BOF

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. ICOS BOF Securing Internet Configuration Bernard Aboba Microsoft IETF 62, Minneapolis, MN

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

  3. 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)

  4. 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)

  5. 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

  6. 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)

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

  8. 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

  9. 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/DHCP • 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)

  10. 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.

  11. 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

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

  13. 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 802.11i defines EAP over IEEE 802.11 • 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

  14. 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

  15. 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)

  16. 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?

  17. 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?

  18. Feedback?

More Related