Transcript PPT Version

draft-ietf-aaa-diameter-mip-15.txt
Tom Hiller et al
Presented by Pete McCann
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)
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
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
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
Redirect on AMR/AMA
FA
AAAF
Local redirect
Agent
Home
Server
AMR
---------------->
AMA (Redirect)
---------------->
AMA (Redirect)
<---------------AMA (Redirect)
<---------------Setup Security Association
<-------------------------------------------------->
AMR
-------------------------------------------------->
AMA (MN-FA key)
<--------------------------------------------------Figure 3: Use of a Redirect Server with AMR/AMA
Redirect on HAR/HAA
HA
Local Redirect
Agent
Home
Server
HAR
<-------------------HAA (Redirect)
-------------------->
Setup Security Association
<---------------------------------------->
HAR (MN-HA key)
<----------------------------------------HAA
----------------------------------------->
Figure 4: Use of a Redirect Server with HAR/HAA
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.
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.
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.
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
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.
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?
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
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 aaakeys. 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.
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
Backup: Previous Collocated CoA Logic
1.
2.
3.
4.
5.
6.
•
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.
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
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