draft-ietf-aaa-diameter-mip-15.txt

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 didnt
  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
• The security associations referred are mobility
  security associations from MIPv4. See next slide
• 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
• 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 others MIP Requests and
  Replies. The AAAH authenticate the FA and HA via
  TLS or IPSec
• The mobile (or AAAH) identifies the HA the FA
  identifies itself via an Diameter AVP
• 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
  drafts approach
• Is there a good reason to delete them?

14
Issue 445 Radias 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 cant. 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 dont use Kerberos
• Unscalability in an inter-domain environment
• Lack of extensibility with authorization
  attributes
• Tickets are bound to IP addresses, which isnt
  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 mobiles 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

• The HA generates a MIP Reply, encoding the MN-HA
  and MN-FA nonces into the MIP Repy in accordance
  with aaa-keys
• The Diameter HAA message transports the MIP Reply
  to the AAAH
• 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
• The FA extracts the MN-FA and FA-HA keys and SPI
  and sends the MIP Reply to the mobile.
• 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

• The HA proxies the mobiles RRQ with MN NAI, AAAH
  NAI, and challenge with challenge response in a
  Diameter AMR message to the AAAH via proxies, as
  necessary.
• 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.
• The Diameter AMA message transports an MN-HA key
  and associated nonce to the HA via proxies as
  necessary
• The HA generates a MIP Reply, encoding the MN-HA
  nonce into the MIP Repy
• The HA sends the Reply to the mobile
• 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 doesnt exist) and use that
  to communicate directly to the AAAH.
• This eliminates intermediary proxies