1 / 11

Securing Zeroconf Networks Draft: Approaches and Challenges

This draft explores the challenges and approaches to securing Zeroconf networks using IPSec and individual protocol security. It evaluates the use of IPSec for securing Zeroconf protocols, discusses characteristics, and concludes with recommendations for improving confidentiality in candidate protocols.

jaquelyn-dickerson
Télécharger la présentation

Securing Zeroconf Networks Draft: Approaches and Challenges

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. Securing Zeroconf Networksdraft-williams-zeroconf-security-00.txt Aidan Williams Motorola Australian Research Centre Aidan.Williams@motorola.com Steve Hanna Sun Microsystems Steve.Hanna@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.Probably not good enough.

  5. Evaluate Two Approaches • Use IPSec to provide network layer security • 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 DSA+SHA-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

More Related