Re: New Radius/Diameter authentication and key delivery for FMIP application

[Jari Arkko <jari.arkko@piuha.net>]

Narayanan, Vidya wrote:

> 
>Re-sending with individual email addresses, since sec-ads@tools.ietf.org
>and ops-ads@tools.ietf.org seem to bounce back. 
>  
>
Oops, I didn't realize those addresses did not exist. Well, Henrik
may have them working right now but in any case, here's my
original e-mail for the benefit of those who lost it:

I would like to open a discussion about support for new
Radius and Diameter applications that support authentication
and key generation.

BACKGROUND

The case in front of ourselves is from MIPSHOP WG.
There is a charter item that specifies the use  of AAA
for  providing FMIP security. Vidya has written a draft,
draft-vidya-mipshop-handover-keys-aaa-03.txt that is a
specific proposal in this space, currently she is asking for the
document to become a WG item in MIPSHOP. The document has
some specific FMIP protocol bits, but it also introduces a new
transaction for RADIUS and Diameter, with the expectation that
sufficient RADIUS and Diameter extensions be developed for
this (the charter does not say where). The new transactions
provide both authentication and key delivery. Vidya's
draft also notes that it may be possible to apply this scheme
in other contexts beyond FMIP, such as context transfer
or HMIP, all of which may require secure communication
between the mobile node and a node within the access
network.

In terms of process there's been reviews within the WG
as well as from secdir and mdir, and the WG wants this.
My understanding is that all issues uncovered in those
reviews have been addressed. We've also had a discussion
with the RADEXT chairs about this, and there was concern for
developing RADIUS key generation mechanisms -- as this has
proven to be difficult in the past. But there was no final
conclusion. Finally, the WG chairs have talked to
Dime chairs who are willing to take on the Diameter
part of the work.

POSSIBLE CONCERNS

First of all, I don't want to take on work if it runs
into significant problems in parts that MIPSHOP
does not own.

Secondly, I worry about the practical impacts
to AAA infrastructures. Having a new "transaction"
or application implies that additional support may
be needed before this can actually be used.

Thirdly, I worry about doing only Diameter work
for this function. It seems likely that some
potential users of FMIP technology run a RADIUS
infrastructure, and adopting this particular
FMIP authentication scheme may therefore
in practise imply adopting a RADIUS extension
for this.

QUESTIONS

I would be interested in input on the following
questions:

1. Confirm whether or not a new transaction
    like this is feasible for both RADIUS and Diameter
    from a technical and process point of view.

2. Is there a reason to worry about developing
    only Diameter support for this function?

3. Are there alternate ways to achieve the same
    thing that would not have the above issues?
    For instance, is there a way to use existing
    AAA infrastructure  and messaging to achieve
    the same functionality?

Suggestions on how to deal with this topic
in general are also welcome.