Securing Zeroconf Networks draft-williams-zeroconf-security-00.txt

1
Securing Zeroconf Networksdraft-williams-zerocon
f-security-00.txt

• Aidan Williams
• Motorola Australian Research Centre
• Aidan.Williams_at_motorola.com
• Steve Hanna
• Sun Microsystems
• Steve.Hanna_at_east.sun.com

2
Presentation Outline

• Background
• Characteristics
• Evaluate two approaches
• Use IPSec
• Secure various protocols
• Conclusion

3
Background

• Security requires configuration
• Is not pure zeroconf
• Can be done within the spirit of zeroconf?
• Motivating scenarios
• Adhoc networks
• Home networking

4
Characteristics

• Want to form groups of devices which can
  communicate securely, with ease
• Assume that there is some kind of secret sharing
  scheme available
• Zeroconf protocols often check for configuration
  servers
• Security in candidate protocols is usually
  limited to request/response authentication.Probab
  ly not good enough.

5
Evaluate Two Approaches

1. Use IPSec to provide network layer security
2. Secure candidate protocols individually

6
IPSec for ZC security

• Pre-shared secret used to authenticate IKE
  Phase-1, unicast SAs negotiated as usual
• IKE cannot be used to negotiate SAs for multicast
  and broadcast
• Can either
• Configure an SA and SPI on devices manually
  when the secret is shared
• Wait for smug/msec to define protocols

7
Proto interface configuration

• IPv4 link local relies on claim/collide using
  ARP. ARP as specified cannot be secured.
• IPv6 address autoconfiguration uses claim/collide
  with IP multicast neighbour discovery
• If we secure IP multicast with IPSec,we secure
  neighbour discovery
• Thus we can secure IPv6 interface config

8
Proto multicast DNS

• DNS is secured using DNSSEC
• Resolver starts with a trusted key, builds paths
  to other zones retrieving and verifying KEY and
  SIG RRs from the DNS.
• Use pre-shared secret for SIGs
• DNSSEC does not
• Provide confidentiality
• Authenticate requests

9
Proto SLPv2

• Optional authentication
• No confidentiality
• Authentication mandates DSASHA-1 digital
  signature
• Could
• Pre-share a DSA key-pair
• Add another authentication scheme and ignore the
  DSA one

10
Proto AutoAAP

• Claim/collide
• Recommends the use of IPSec for security,
  specifies no additional mechanisms
• Uses multicast, therefore needs shared SA/SPI

11
Conclusions

• Bootstrapping IPSec seems promising
• The candidate protocols described need
  significant work, in particular to support
  confidentiality
• Having one scheme which covered all the protocols
  would be really nice