MIPv4-Diameter Update

1. MIPv4-Diameter Update Tom Hiller Lucent Technologies

2. Review • Registration Support • Static Home Agent with static or dynamic home address • Dynamic Home Agent • AAAH assigns HA in home network; static or dynamic home address • AAAF assigns HA in visited network; dynamic home address only • Key distribution • MN-FA and MN-HA keys to FA/HA • AAA Keys distribute nonces to mobile

3. “AAA Keys” Heads-Up • AAA Keys delivers the MN-FA and MN-HA keys to the mobile • Mechanism: nonces generated by the AAAH • AAA Keys is worked in the MIP WG • Recent “AAA Keys” revision: • Clarifies use with Diameter and RADIUS • A fix to small error as part of a last call

4. Security Update Needed • Recent Events: • AAA WG drops support of CMS • Security Guidance: Only those entities that use a key shall have the key • Implication: • Draft sends keys in the clear through the AAAF • But, keys must not be exposed to the AAAF • Therefore, a different mechanism is needed

5. Redirect Solution • Use “Redirect” to eliminate AAAF (and brokers) from message transaction • MIPv4-Diameter involves the MN, AAAF, AAAH, FA and HA. • The HA may be assigned by the AAAF or the AAAH • Not clear to the author how to eliminate the AAAF involvement with redirect

6. 3GPP2 and AAAF • 3GPP2 typically allows AAAF policy to override attributes from the AAAH • Eliminating AAAF involvement from AAA responses pushes policy decisions to the FA • Preferable that AAAF stay in message exchange

7. Key Distribution Messages • Delete the key AVPs from AMA/HAR • Abandon CMS and hop-by-hop security • TLS session to directly transport keys • One TLS session between AAAH and FA • One TLS session between AAAH and HA • New Diameter commands allocated • Key Request: HA or FA requests key from AAAH • Key Reply: AAAH provides keys • See suggested flow in subsequent slide

8. Visited Network Allocates the HA

9. Home Network Allocates the HA

10. MN-FA Key Distribution

11. Discussion • Security • Only the HA and FA see the keys; AAAF and brokers do not see the keys • Assumptions: Visited network FA, HA, and AAAF are trustworthy • Latency • May create extra registration latency • AAAF involvement • AAAF sees authorization attributes

12. 3GPP2 AAA Trust/Security Model • All AAA nodes are trustworthy • All AAA communications over public facilities are encrypted • However: Next slide considers a rouge AAA node attack on HA assignment in visited network

13. Security Threat? • Hypothetical Attack • The AAAF allocates an HA for the user • A rouge broker AAA node changes the HA address or HA identity to a rouge HA • The AAAH provides the MN-HA key to that HA; that HA calculates the MIP Reply • The mobile gets the wrong HA in the MIP Reply • Potential Solutions: • The home network verifies the HA belongs to the visited network and not some other network • The visited network verifies the HA in the Reply is the same as it allocated; the AAAH will not over ride an AAAF allocation of an HA, but may refuse the RRQ

14. Proposed Plan • Review of these slides ~3 weeks • Review an edit on the current draft • Use MSFT Word revision control on txt • Post that edit in *doc, *pdf, and *ps form • ~ 3 weeks • Post a new version of the draft • Contingent on “AAA Keys” progressing satisfactorily • ~ 3 weeks

15. Conclusion • Proposed plan • Leaves most of the current draft message flows intact • Creates two new Diameter messages • Renders keys visible only to those entities that need the keys • Leaves the AAAF involved to make policy decisions on the attributes returned to the FA • Creates new draft in ~9 weeks, assuming “AAA Keys” progresses