MIPv4-Diameter Update Tom Hiller Lucent Technologies

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

“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

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

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

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

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

Visited Network Allocates the HA

Home Network Allocates the HA

MN-FA Key Distribution

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

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

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

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

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