ICOS%20BOF

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 cant
  obtain inner address without a tunnel mode SA)
• Alternative mechanism still needed for other
  configuration parameters

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?