Guidance for Authentication, Authorization, and Accounting (AAA) Key Management
RFC 4962

Note: This ballot was opened for revision 09 and is now closed.

(Jari Arkko) (was Discuss) Yes

Comment (2007-02-12)
No email
send info
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

Comment (2007-04-26)
No email
send info
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' **)
No email
send info
(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.

(Mark Townsley) No Objection

(Russ Housley) Recuse