Securing Internet Layer Configuration

1
Securing Internet Layer Configuration

• IAB Tech Chat
• January 25, 2005

2
Outline

• What is IP Configuration?
• Problem definition
• Architectural Principles
• Literature Review
• Recommendations

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
• Focus of todays tech chat
• 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

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
Relevant 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

8
Less is More

• 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

• Multi-homed hosts becoming more popular
• Examples WWAN/WLAN phones
• Desirable for hosts to be able to configure
  themselves on multiple networks without adding
  configuration code specific to a new link layer.
• Counter-examples
• RFC 903 (RARP) superceded by BOOTP/DHCP
• 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)
• DHCPINFORM defined in RFC 2131, subsequently
  implemented over PPP
• PPPEXT WG has resisted equivalent IPv6CP
  extensions
• IPCP allocation no longer FCFS, requires IETF
  Consensus (RFC 3818)
• 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
• Alternative is multi-stage setup, snopping of IP
  address configuration by VPN server (RFC 3456)

10
Higher Layer Independence

• To reduce complexity, desirable for configuration
  mechanisms to avoid dependence on higher layers
• Embedded hosts may wish to minimize boot ROM code
• Availability of higher layer facilities cannot be
  guaranteed
• Many boot ROMs support IP/UDP, dont support
  TCP/SCTP
• Embedded systems may not have headroom for
  complex higher layer protocols (LDAP, SSL/TLS,
  etc.)

11
Rely on the Internet Layer

• If both lower and higher layer dependencies are
  undesirable, then IP configuration (security)
  needs to depend only on the Internet layer.
• However, 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
• Examples
• BOOTP, DHCPv4, DHCPv6, RS/RA

12
Literature Review

• DHCP security
• DHCPv4
• DHCPv6
• SEND
• EAP-based approaches

13
DHCPv4 Security (RFC 3118)

• Extensible framework for authentication,
  integrity/replay protection of DHCP messages
• Protocol, Algorithm, Replay Detection Mechanisms
  are extensible
• Security services vary by protocol
• Draft defines two protocols
• Cleartext token weak entity authentication and
  no message authentication only useful against
  accidental DHCP servers
• Pre-shared key authentication (delayed
  authentication)
• Client requests authentication in DHCPDISCOVER or
  DHCPINFORM
• Server provides authentication option in
  DHCPOFFER/DHCPACK
• Client send authentication option in DHCPREQUEST
• Requires a shared secret key for each client on
  each DHCP server the client may wish to use
• Issues
• Neither protocol addresses inter-domain roaming
• Delayed authentication protocol doesnt scale
  well within a domain
• Appendix A suggests generation of the key from a
  master key and (DHCP client-identifier, subnet
  address), so as to avoid centralized key
  management
• While this avoid requiring DHCP server access to
  cleartext passwords, it requires hosts to
  re-provision when new interfaces are added
• Deployment
• No known usage by any commercial or private
  implementation since its adoption.

14
DHCPv6 Security (RFC 3315)

• Based on DHCPv4 authentication (same security
  services provided)
• Improvements
• Defines DHCP Unique Identifier (DUID)
• Each DHCP client and server has exactly one DUID
• Defines DHCP realm
• Name used to identify the DHCP administrative
  domain
• Defines key indexing model
• Key identified by ltDHCP Realm, client DUID,
  keyidgt
• Defines use of IPsec for securing messages
  between relay agents and servers
• Appendix A key management scheme omitted
• Authentication mechanisms
• Defines the delayed authentication and
  reconfigure key protocols
• Reconfigure key protocol used to protect against
  sending of reconfigure messages by a rogue DHCP
  server
• DHCP server sends a reconfiguration key in the
  initial DHCP exchange
• Issues
• Inter-domain scaling

15
SEND

• Draft-ietf-send-ndopt (now in RFC Editor queue)
• Provides data origin authentication,
  integrity/replay protection services
• Asymmetric authentication scheme
• Address authorization demonstrated via proof of
  possession of corresponding private key
• Cryptographically generated addresses (CGAs)
  defined in draft-ietf-send-cga-06
• Effective strength of CGAs varies based on the
  security parameter Sec, RSA Key Length (gt 384
  bits)
• Routers certified via a trust anchor
• Hosts configured with a set of trust anchor(s)
  for Router Discovery (X.509 certificates)
• Certification path solicitation and advertisement
  messages used to discover path to a trust anchor
  out-of-band

16
EAP- based Approaches

• Several variants
• EAP used at the link layer to derive keys
  subsequently used to secure IP configuration
• Example draft-yegin-eap-boot-rfc3118-00.txt
• EAP embedded within the configuration protocol
• Example draft-ietf-ipsec-ikev2-17.txt
• No EAP on the wire, but RADIUS/EAP used to
  provide for AAA support
• May use the EAP key hierarchy, but not EAP
• Issues
• EAP is media independent, but not all link layers
  support it
• EAP mandatory-to-implement method (MD5) does not
  provide mutual authentication or generate keys
• Security model not well defined
• Existing proposals have no mandatory-to-implement
  authentication method
• Change from a 3 party protocol (EAP client,
  authenticator, EAP server) to a 4 party protocol
  (client, authenticator, config server, EAP
  server)
• Synchronization issues
• EAP does not provide key management facilities
  (key installation/deletion, key lifetime
  negotiation)
• Multiple keys may exist between config client and
  server
• How does config client negotiate which key to
  use?

17
Some Thoughts

• Inter-domain Support
• Transition Issues
• Provisioning Issues

18
Inter-Domain Support

• All approaches challenged by inter-domain roaming
• DHCP
• DHCPv4 does not provide support for realms
• DHCPv4 client needs to be pre-provisioned for
  each DHCP server it might encounter
• DHCPv6 supports realms pre-provisioning problem
  still exists
• SEND
• Clients can accept configuration from any server
  whose chain of trust can be verified
• Requires provisioning of trust anchors
• Difficulties with certificate revocation
• EAP
• Long-standing support for inter-domain roaming
• Can support a wide variety of credentials
• Determination of the realm occurs outside EAP
  (often insecurely)
• Link layer discovery
• EAP identity selection

19
Transition Issues

• All approaches experience transition difficulties
• Mixture of secure/insecure configuration clients,
  secure/insecure configuration servers likely to
  persist for a long time
• Insecure client can interoperate with secure
  server only if client security not required by
  server
• Useful to be able to secure server packets
  without requiring client authentication (DHCPv4
  threat model)
• When can a security-capable client require server
  security?
• When all servers encountered by the client
  support security
• Client can then ignore insecure configuration
  offers
• Example if all realms client may roam to are
  secure (e.g. homogeneous deployments of captive
  devices)
• Doesnt work if even one visited realm has even
  one insecure server
• Attacker can impersonate an insecure server in an
  insecure realm, fool client into thinking it is
  in the wrong realm, and provide bogus
  configuration
• Less secure transition policies
• Allow insecure configuration when client doesnt
  receive any secure configuration (allows mixture
  of secure insecure servers)
• Provide configuration to insecure clients
• Enables DoS attacks against configuration servers

20
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?

21
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 need to be
  provisioned in NVRAM
• How many different credentials are required?
• Shared secrets, Trust anchors, etc.
• How much boot ROM code is required?
• Certificate handling requires substantial
  footprint
• Boot ROM code often runs in REAL mode
• Does each boot ROM need to be individually
  provisioned?
• Unique shared secret/certificate for each client?
• Same set of trust anchors

22
Initial Provisioning (contd)

• SEND
• Same set of trust anchors can be provisioned on
  each host
• Host can generate public key on initial boot
• DHCP
• Requires provisioning of unique shared secret
• EAP
• Requires provisioning of unique credential

23
Re-Provisioning

• Scenario Configuration server certificate is
  compromised
• Example router is compromised, private key
  revealed.
• How do clients check the CRL?
• Need IP configuration to check the CRL (e.g. at
  least an IP address)
• Difficult to add support for OCSP to
  configuration protocols
• Some ideas
• Short duration for configuration server
  certificates

24
Summary
25
Recommendations

• Approach used by SEND appears to be the best
  match to the problem
• Messages are integrity/replay protected
• Client proves authorization to use address, but
  doesnt authenticate to server
• Server authenticates to client via chain of trust
• Requires provisioning of trust anchors on client
• Security provided at the Internet layer
• No dependence on link or higher layers
• No client-specific provisioning
• Need to think through certificate revocation
  issues
• What about stateful configuration?
• DHCPv6 supports extensible security
• Server could sign messages, client verifies via
  pre-provisioned trust anchors
• Without client authentication, would not address
  DoS attacks
• What about DHCPv4?
• Could add a mechanism for server-only
  authentication
• Would also need better realm/identity support to
  enable inter-domain roaming