1 / 7

A Scheme for MN-MAP Security in HMIPv6

This document proposes a security scheme for mobile node (MN) and mobility anchor point (MAP) communication in Hierarchical Mobile IPv6 (HMIPv6) networks. It addresses the need for security in the exchange of binding updates between MNs and MAPs, and introduces two security modes for different scenarios. The proposed scheme provides authentication and authorization between MNs and MAPs, without relying on a global public key infrastructure (PKI).

lcharlene
Download Presentation

A Scheme for MN-MAP Security in HMIPv6

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. A Scheme for MN-MAP Security in HMIPv6 draft-qiu-mipshop-mn-map-security-00.txt Jianying ZHOU Feng BAO, Robert DENG, Ying QIU Institute for Infocomm Research, Singapore

  2. HA CN Internet MAP AR2 AR1 movement MN MAP’s Domain Why need security between MN and MAP? • When CN sends packets to MN's RCoA, MAP intercepts the packets and forwards them to MN's LCoA. • Redirect Attacks: if BU message from MN to MAP is not authenticated when MN changes its AR, an attacker can redirect traffic from MAP to fake destinations. • Only the authorized users can use the MAP HA: Home Agent CN: Correspondent Node MAP: Mobility Anchor Point AR: Access Router MN: Mobile Node

  3. MN MAP Cookie0 Cookie1 long term messages BU1 BA1 BUi short term messages BAi How to Provide MN-MAP Security? Authentication-only Mode In this mode, a MAP only needs to ensure that the same MN is sending the BUs to the MAP. It is not necessary for the MN to prove that it is authorized to use a MAP to manage its mobility. • Cookie0 = {Src=LCoA, Des= MAP, Opt=HoA, C0} • Cookie1 = {Src=MAP, Des=LCoA, Opt=HoA, C0, C1, N1}. • BU1 = {Src=LCoA, Des=MAP, Opt=HoA, C0, C1, N1, N2, TS, SIGMN, CertMN}, • SIGMN = Sig(SKMN, LCoA|HoA|MAP|N1|N2|TS). • BA1 = {Src=MAP, Des=LCoA, Opt=HoA, RCoA, C0, C1, N1, N2}, • BUi = {Src=LCoA, Des=MAP, Opt=HoA, old_LCoA, TS, SIGMN_i} • SIGMN_i = Sig(SKMN, LCoA|MAP|HoA|old_LCoA|TS). • BAi = {Src=MAP, Des=LCoA, Opt=HoA}

  4. MN MAP HA Cookie0 Cookie1 long term messages BU1 Req_cert Rep_cert BA1 BUi short term messages BAi How to Provide MN-MAP Security? Authentication & Authorization Mode • In this mode, the MAP and the MN need to know that the other end is "trusted". The MAP also needs to know if the MN is authorized for using it. • All 3 parties need certificates; MN’s is issued by its HA • Both MAP and HA only need to store a few trusted CAs’ public keys. • Similar to SSL, no global PKI is need here.

  5. MN MAP HA Cookie0 Cookie1 BU1 Req_cert Rep_cert BA1 BUi BAi How to Provide MN-MAP Security? Authentication & Authorization Mode • BU1 = {Src=LCoA, Des=MAP, Opt=HoA, C0, C1, • N1, N2, TS, gx, SIGMN, CertMN}, • SIGMN = Sig(SKMN, LCoA|HoA|MAP|gx|N1|N2|TS) • CertMN = {HoA, PKMN, Valid_Iinterval, SIGHA} • Req_Cert = {Src=MAP, Des=HA, request_cert} • Rep_Cert = {Src=HA, Des=MAP, CertHA} • BA1 = {Src=MAP, Des=LCoA, Opt=HoA, RCoA, C0, C1, gy, SIGMAP, CertMAP} • SIGMAP = Sig(SKMAP, LCoA|HoA|MAP|gy|BU1) • CertMAP = {MAP, PKMAP, Valid_Iinterval, SIGCA} • BUi = {Src=LCoA, Des=MAP, Opt=HoA, old_LCoA, TS, SIGMN_i} • BAi = {Src=MAP, Des=LCoA, Opt=HoA, SIGMAP_i}

  6. Conclusion • The proposal considers security issues in binding update between mobile nodes and a mobility anchor point. • Proposed solution for the above, with two security modes for different scenarios. • Authentication of MN without the global PKI.

  7. Q & A Thank You

More Related