[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New Radius/Diameter authentication and key delivery for FMIP application
> 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
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
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