Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4
RFC 3957

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

(Thomas Narten) Yes

(Harald Alvestrand) No Objection

(Steven Bellovin) (was Discuss) No Objection

(Margaret Cullen) No Objection

(Ted Hardie) No Objection

Comment (2004-04-27 for -)
No email
send info
In the introduction, the  3rd paragraph says:

   It is assumed that the AAA Security
   Association between the MN and its HAAA has been appropriately
   configured so that the AAA server has the authorization to provide
   key material to be used as the basis for the necessary Mobility
   Security Assocation between the MN and its prospective mobility
   agents.

The 4th paragraph says:

   It is assumed that the security association between the
   mobile node and its AAA server has been appropriately configured so
   that the AAA server has authorization to provide key material to be
   used as the basis for the necessary Mobility Security Association(s)
   between the mobile node and its prospective mobility agents.

Is this redundant, or meant to be introducing a different assumption
(related to the AAA server versus the HAAA server)?  If the latter, some
further text clarifying it would be useful.  If the first one is retained
"Assocation" is missing an "i".

The document is very clear that:


   The provisioning and refreshing of the AAA key in the MN and AAA
   server is outside the scope of this document.

Is there is a pointer to  a document or set of documents that describe
the provisioning and refreshing practices in use or a perceived set of
best practices for this?  If such a pointer or pointers were available,
they would be welcome additions as informative references; there
does seem to be a risk here that folks will pre-provision essentially
static AAA keys, and though this document is quite clear that it is not
its task to clear that up, any available pointers would be welcome.

(Scott Hollenbeck) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2004-04-27)
No email
send info
  Section 4: s/supported replay methods/supported replay detection methods/

  Section 5 title: s/and Derivation/and Key Derivation/

  Section 5: s/The example that follows makes use of/The following example uses/

(David Kessens) No Objection

(Allison Mankin) No Objection

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection