1. draft-ietf-aaa-diameter-mip-15.txt Tom Hiller et al Presented by Pete McCann

2. Outline Basic operation of Diameter-MIPv4 Summary of changes Responses to Steve Bellovin issues Backup slides: tutorial review –(included for convenience, but not covered during presentation)

3. Purpose of Draft Support MIP registration for both FA CoA and collocated CoA modes of MIP operation. Support robust assignment of dynamic HA in the home or visited network Support MIPv4 key distribution for MN-HA to the HA, MN-FA to the FA, and FA-HA to the FA and HA; keys are generated by the AAAH. This draft requires the aaa-key draft (from mip4 wg) to deliver nonces to the mobile

4. Issues As Diameter distributes keys to the HA and FA, the keys are exposed to any and all Diameter Agents between the AAAH and the FA or HA –Security guidance indicates that only those entities that need to see the keys should have access to them –The AAA WG terminated the CMS application, so it is not available to encrypt keys from untrustworthy Diameter Agents; in addition, CMS text must be deleted After a MIPv4 handoff from visited network 1 to visited network 2, if visited network 1 didn’t want to support an HA for the mobile, the mobile would have to acquire a new HA. –No requirement for this, at least from 3GPP2

5. Redirect Server Added a Diameter Redirect Server that permits the FA or HA to establish a security association (TLS or IPSec) directly to the AAAH –All intermediary Diameter Agents, including the AAAF are eliminated from the authentication and authorization. Accounting and session termination occur via AAA proxies The Diameter transaction plus key distribution then takes place over the security associations

6. Redirect on AMR/AMA

7. Redirect on HAR/HAA

8. Item 1.6 Steve Bellovin: What is a "preconfigured shared security association"? Do you mean a preshared secret? A security association comprises far more than just a key. I have not evaluated the security of the scheme in this section, since it depends on another draft, and possibly on the security of MobileIP itself. Can we really even consider this draft until those are done? Response: 1.The security associations referred are mobility security associations from MIPv4. See next slide 2.draft-ietf-mobile-aaa-key-01.txt underwent a security review and a number of edits. It will go to IETF LC soon.

9. Mobility Security Association From aaa-key: A Mobility Security Association is a simplex connection that applies security services to RFC 3344 MIPv4 control traffic between a MN and HA (or MN and FA) using RFC 3344 Authentication Extensions. A Mobility Security Association is uniquely identified by the peer source and destination IP addresses and an SPI. Two nodes may have one or more Mobility Security Associations; however, typically there is no reason to have more than one Mobility Security Association between two nodes.

10. Item 1.10: Steve Bellovin: What firewall rules? Are the agents supposed to tell their local firewalls to open up some holes? Response: –Firewall pinholes are outside the scope. If firewalls are present then the firewalls need to be configured to allow traffic between mobility agents, between mobility agents and AAA servers, and between AAA servers –I asked Russ Housely about having to have pinholes to distribute keys vs trusting the AAAF, and he stated it was preferable to have pinholes in the firewalls, that is, assuming there are any such firewalls.

11. Item 5.2 Steve Bellovin: 64 bits is not sufficient for a key. Why not just mandate 128, instead of strongly recommending it? Response: Was changed to 128 in aaa-keys

12. Item 5 Steve Bellovin: I confess that it still isn't clear to me how the home and foreign agents know authoritatively who each other are. Then again, that's always been my main complaint about AAA. But here they're handing out keys. Response: 1.In this draft, the FA and HA can request an FA-HA key from the HAAA of the user. The FA and HA can then authenticate each other’s MIP Requests and Replies. The AAAH authenticate the FA and HA via TLS or IPSec 2.The mobile (or AAAH) identifies the HA; the FA identifies itself via an Diameter AVP 3.Lastly, the draft only assumes the AAAH, FA, and HA are trustworthy.

13. Remaining Issues and Questions Who picks the SPI for the FA-HA mobility association? –Previous draft: the AAAH –Current draft: the FA Can the AAAF also act as a Redirect Server? –The Redirect Server is stateless; in this mode the AAAF does not participate in the authentication and authorization transaction, so it could act as a Redirect Server. Does this draft need to point out that a visited FA or HA could contact a local AAA server for a policy review of AVPs in authorization from the AAAH? –We can add this as a stand alone scenario that applies to any of he current scenarios; it adds latency for the user to receive service. Original draft flows without a Redirect Server were left intact for continuity with previous drafts, similar to the current Diameter-EAP draft’s approach –Is there a good reason to delete them?

14. Issue 445: Radia’s Review “The document is incomprehensible” –We will rewrite the introduction “So in the case of inter-realm, the intermediaries would see the keys.” –No, they can’t. TLS connections are end-to-end. “…instead of a Kerberos-like protocol where the session key is encrypted in a KDC-endpoint shared secret…” –Good reasons why we don’t use Kerberos: Unscalability in an inter-domain environment Lack of extensibility with authorization attributes Tickets are bound to IP addresses, which isn’t what we want High latency at handoff time Tickets too large for embedding in Mobile IP messages Dictionary attacks in a wireless medium

15. Backup: Previous FA CoA Logic 1.The FA proxies the mobile’s RRQ with MN NAI, AAAH NAI, and challenge with challenge response in a Diameter AMR message to the AAAH via proxies, as necessary. 2.The AAAH authenticates the mobile, selects an HA, generates (if requested) the MN-FA and/or MN-HA session keys and SPIs, along with associated nonces for the mobile, and the FA-HA key, in accordance with aaa- keys. The AAAH also generates the FA-HA key and SPIs. 3.The Diameter HAR message transports the RRQ to the HA, including the MN-HA and FA-HA keys and SPIs, nonces, and HA-FA key and SPI via proxies, as necessary.

16. Backup: FA CoA Logic continued 4.The HA generates a MIP Reply, encoding the MN-HA and MN-FA nonces into the MIP Repy in accordance with aaa-keys 5.The Diameter HAA message transports the MIP Reply to the AAAH 6.The AAAH adds MN-FA key and SPI, and the FA-HA key and SPI, to a Diameter AMR message and sends that to the FA via proxies, as necessary 7.The FA extracts the MN-FA and FA-HA keys and SPI and sends the MIP Reply to the mobile. 8.The mobile extracts the nonce, generates the MN-HA and MN-FA keys, and authenticates the Reply before using it The last step completes a mutual authentication between the AAAH, mobility agents, and the mobile

17. Backup: Previous Collocated CoA Logic 1.The HA proxies the mobile’s RRQ with MN NAI, AAAH NAI, and challenge with challenge response in a Diameter AMR message to the AAAH via proxies, as necessary. 2.The AAAH authenticates the mobile, and generates, if requested, a session key and SPI for HA along with an associated nonce for the mobile, per aaa-keys. 3.The Diameter AMA message transports an MN-HA key and associated nonce to the HA via proxies as necessary 4.The HA generates a MIP Reply, encoding the MN-HA nonce into the MIP Repy 5.The HA sends the Reply to the mobile 6.The mobile extracts the nonces, generates the key, and authenticates the Reply before using it The last step completes a mutual authentication between the AAAH, mobility agents, and the mobile

18. Backup: Current Identical flows except the Redirect Server intercepts the initial AMR or HA message and causes the FA or HA to establish a security association (if one doesn’t exist) and use that to communicate directly to the AAAH. –This eliminates intermediary proxies