Guidance for Authentication, Authorization, and Accounting (AAA) Key Management
Note: This ballot was opened for revision 09 and is now closed.
(Jari Arkko) (was Discuss) Yes
My Discuss has been cleared based on the new version -07 that Russ Housley prepared.
(Sam Hartman) (was Discuss, Yes) Yes
(Ross Callon) No Objection
(Brian Carpenter) No Objection
(Lisa Dusseault) No Objection
Lars Eggert No Objection
(Bill Fenner) No Objection
(Ted Hardie) No Objection
(Cullen Jennings) No Objection
(David Kessens) No Objection
(Chris Newman) No Objection
Minor comments: Section 2, last paragraph: OLD: however, other parties may receive keys that is derived from this ^^ NEW: however, other parties may receive keys that are derived from this Section 3, > Cryptographic algorithm independent Although this section implies hash function agility is required, it might be clearer to make that explicit.
(Jon Peterson) No Objection
(Dan Romascanu) No Objection
Comment (2007-01-11 for -** No value found for 'p.get_dochistory.rev' **)
(contributed by AAA doctor David Nelson who reviewed the document and is confortable with its content). The following text in Section 2 seems to be duplicated, and should probably show up only once: However, due to ad hoc development of AAA- based key management, AAA-based key distribution schemes have poorly understood security properties, even when well-studied cryptographic algorithms are employed. More academic research is needed to fully understand the security properties of AAA-based key management in the diverse protocol environments where it is being employed today. In the absence of research results, pragmatic guidance based on sound security engineering principles is needed.