distributing a symmetric fmipv6 handover key using send n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Distributing a Symmetric FMIPv6 Handover Key using SEND PowerPoint Presentation
Download Presentation
Distributing a Symmetric FMIPv6 Handover Key using SEND

Loading in 2 Seconds...

  share
play fullscreen
1 / 22
azure

Distributing a Symmetric FMIPv6 Handover Key using SEND - PowerPoint PPT Presentation

86 Views
Download Presentation
Distributing a Symmetric FMIPv6 Handover Key using SEND
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. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Distributing a Symmetric FMIPv6 Handover Key using SEND Chris Brigham Tom Wang

  2. Security Properties • Mobile Node Authentication • If honest AR finishes the protocol and believes it is talking to honest MN, then the MN believes it is talking to the AR.

  3. Security Properties • Access Router Authentication • If honest MN finishes the protocol and believes it is talking to honest AR, then the AR believes it is talking to the MN.

  4. Security Properties • Handover Key Secrecy • The intruder cannot learn the handover key until MN sends the FBU to AR.

  5. Analysis Overview • Full Protocol • Deconstructed Protocols • Reduce signature scope • Remove nonce option • Remove CGA option

  6. Full Protocol Model

  7. Full Protocol Model • Request (RtSolPr) • MN=>AR: {CGAMN, EPKMN, NMN}[SigMN]

  8. Full Protocol Model • Request (RtSolPr) • MN=>AR: {CGAMN, EPKMN, NMN}[SigMN] • Response (PrRtAdv) • AR=>MN: {CGAAR, {HK}EPK_MN, NMN}[SigAR]

  9. Full Protocol Model • Request (RtSolPr) • MN=>AR: {CGAMN, EPKMN, NMN}[SigMN] • Response (PrRtAdv) • AR=>MN: {CGAAR, {HK}EPK_MN, NMN}[SigAR] • Fast Binding Update • MN=>AR: {CGAMN, HK}

  10. Full Model - Results • Attack found! • “Access Router authenticated” invariant fails • Man-in-the-middle attack • Similar to NS problem • Intended destination not checked for response message E X M MN AR

  11. Full Model – Attack Trace • MN sends request to AR. E intercepts. • E sends new request to AR, using MN’s nonce and handover key encryption key. • AR sends response to E, and E forwards response to MN. • AR actually generated handover key for E, though E cannot read the handover key at this point. • When MN sends FBU to AR with handover key, handover fails.

  12. Valid Attack?

  13. Valid Attack? • In specification draft section 3.2: • “The SEND signature covers all fields in the PrRtAdv, including the 128 bit source and destination addresses …” • Model was missing signature on source and destination addresses • All invariants passed on revised model.

  14. On to Decomposition • Protocol is sufficient to enforce required security properties • Are the features of SEND overkill for handover key distribution?

  15. Reduced Signature Scope • Remove source/destination addresses from the signed portion of each message • Decomposition is identical to the original, broken, full model.

  16. No “Noncense” • How will the protocol behave if signature on nonce is removed? • Replay attack found • “Access Router authenticated” invariant fails

  17. No “Noncense” – Trace • MN and AR complete first session as usual, but E records AR’s response from previous session. • MN reconnects to same AR. • MN sends request for handover with new nonce. E intercepts. • E sends MN AR’s previous response with new nonce. • FBU fails since handover key is not valid.

  18. Removing CGAs • How will the protocol behave if CGAs are removed and replaced with real IPv6 addresses? • Worst case attack found • Access Router authentication invariant fails • Mobile Node authentication invariant fails • Secrecy fails

  19. Removing CGAs - Trace • MN sends AR request for handover, but E intercepts. • E forges the signature, creates his own handover key encryption key and nonce, and sends request to AR. E pretends to be MN. • AR generates handover key and sends it to MN. • E intercepts AR’s response. • E can now issue FBU and get packets meant for MN!

  20. Our Conclusion • The SEND options used for handover key distribution are necessary and sufficient

  21. Our Conclusion • The SEND options used for handover key distribution are necessary and sufficient • We should have known: • From draft, section 13.0: • “The authors would like to thank John C. Mitchell and Arnab Roy, of Stanford University, for their review of the design and suggestions for improving it.”

  22. Questions?