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

[Bernard Aboba <aboba@internaut.com>]

> I hope we can get the AAA support -- but I want to get
> a prior agreement from the relevant folks that this
> is indeed possible even in this case. I worry that there
> *might* be a problem if the Zorn keyreq stuff has been
> stuck for years, too.

To be clear, the issue of appropriate wrapping for a *new* key transport 
attribute is somewhat easier than the problem of achieving RADIUS 
crypto-agility in general. 

If an attribute is *new* then presumably there is no legacy key wrap to 
deal with.  The receiver either understands the attribute or it doesn't. 
The new keying attribute can have an algorithms field so that if the 
default keywrap algorithm is discredited, something else can be used 
instead. 

A bigger issue is the key management *model*.  For example:

a. What assumptions are being made about the functionality of the AAA 
server?  For example, is the server stateless or stateful?  Are keys 
cached? 

b. What are the required properties for the keys?  Are they always fresh?  
Known only by two parties? 

The easiest way to address this is to clearly describe the problem 
and the requirements for a solution.  Shouldn't take more than a page or 
two.