1 / 16

MN-HA Authentication Enhancement

MN-HA Authentication Enhancement. JUNHYUK SONG SAMSUNG ELECTRONICS. Introduction. Dynamic HA allocation is supported in C3 MN need to have MN-HA shared key independent of specific HA. MN-HA shared key is necessary for MIP re-registration with optional Access Request case

redford
Download Presentation

MN-HA Authentication Enhancement

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. MN-HA Authentication Enhancement JUNHYUK SONG SAMSUNG ELECTRONICS

  2. Introduction • Dynamic HA allocation is supported in C3 • MN need to have MN-HA shared key independent of specific HA. • MN-HA shared key is necessary for MIP re-registration with optional Access Request case • Need to have robust and secure way to generate MN-HA key

  3. Proposed solutions • Solution 1 (MN-AAA shared key) • Solution 2 (Static MN-HA key) • Solution 3 (Dynamically MN generate MN-HA shared key by FAC) • Solution 4 (Dynamically generate MN-HA shared key by Key Material) • Solution 5 Same scheme with solution 3 with NVSE

  4. Solution 1 • It requires only one key, therefore easy of maintenance for Mobile Node and AAAH. • This is good security approach, because always less keys is better • The MN-AAA shared key is mandatory because it is used for MN-AAA authentication. • Comply with the Internet Draft, RFC2002 bis 06

  5. Call Flow Solution 1

  6. Solution2 • Mobile has static MN-HA key and MN-AAA key • HA fetches MN-HA key upon receiving RRQ • Less change in current system • Backward compatible • Static MN-HA shared key • Mobile need to manage two keys

  7. Solution 2 call flow

  8. Solution 3 • No need for new MIP extension vs. Solution 4 • MN-HA shared key is session specific vs. Solution 1 and 2 • MN initially only need to know MN-AAA shared key, therefore easy key management • The FAC that issued by Foreign Network has some influence on MN-HA shared key generation • Less robust MN-HA shared key management vs. Solution 4.

  9. MN-HA key Calculation • Mobile Node and AAA shall calculate MN-HA shared key like below • MN-HA shared key = MD5 (MN-AAA-key | FAC | MN NAI | MN-AAA-key) • MN-HA shared key is session specific, • It MAY optionally refresh upon every re-registration • It shall be used until the session is terminated • It shall be used until the pre-configured lifetime expired

  10. Solution 3 Call flow

  11. Solution 4 • Based on draft-ietf-mobileip-aaa-key-07, Currently LAST CALL • Using new MIP extensions type 40~43, non-skipable • More security enhanced approach than Solution 3, because ‘Key Material’ is generated by AAA • More robust MN-HA key management than Solution 3

  12. MN-HA key Calculation • Mobile Request “Key Material” with MN-HA Key Request MIP extension • HA sends request MN-HA request AAA subtype message • AAA generate pseudo random number “Key Material” • MN-HA key = MD5 (AAA-key | Key Material | node-address | AAA-key) • HA fetches MN-HA key and Key Material and then sends RRP with MN-HA Key Reply Extension

  13. Solution 4 Call Flow

  14. Solution 5 • Same Key generation scheme with Solution 3 • No need to IETF approval • The initial RRQ authenticated by VS. Solution 4 • Better Key Management VS. Solution 3 • Using MIP NVSE extension for key management • Better backward compatibility than Solution 4 • Support of MN reboot case • Support of HA reboot case

  15. Solution 5 MN refresh key call flow

  16. Solution 5 HA refresh key call flow

More Related