Another thing that bothers me is the direct reference to AES. Introducing a dependency on any one algorithm does not constitute agility in any sense of the word. The point (imho) is not to demonstrate how much we trust AES today but to make sure radius doesn't have to go through this again when AES needs replacing.
It is fine (required, really) to specify and reference a mandatory-to-implement algorithm for each usage. This includes not only keywrap but also the MIC. However, it should also be possible to negotiate alternative algorithms. That requires a mechanism negotiate algorithms, as well as IANA considerations to allocate code points to additional algorithms beyond those specified in the document.
Are you saying that any of these things is missing from the document? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>