Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4
draft-ietf-mip4-aaa-key-06

[Note]: '2004-05-19: -05 has been submitted; need to followup with IESG to get discusses cleared. Oops, not every comment addressed, it appears.' added by Thomas Narten

[Note]: '2004-04-07: -04 is out, ready for IETF LC!  Note: draft-ietf-aaa-diameter-mobileip-16.txt is waiting on this document; a security review of diameter-mobileip can''t be done without also reviewing aaa-key.
Participant in PROTO Team pilot:
Working Group Chair Followup of DISCUSS Comments
http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-discuss-pilot-01.txt' added by Margaret Wasserman

[Ballot discuss]
In Section 5, there is text saying

      key = HMAC-SHA1 (AAA-key, {Key Generation Nonce || home
          address})

What if there is no home address?  Is the NAI to be used, per the discussion a few lines earlier?

[Ballot discuss]
Section 5 says: "... MUST implement HMAC-SHA1 [1].  Other cryptographic
  functions MAY also be used."  However, the manner in which the function
  is selected needs to be discussed.  Further, not all cryptographic
  functions are acceptable.  Please provide the reader with some guidance.

[Ballot comment]
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/

[Ballot comment]
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.

[Ballot comment]
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)?

[Note]: '2004-04-07: -04 is out, ready for IETF LC!  Note: draft-ietf-aaa-diameter-mobileip-16.txt is waiting on this document; a security review of diameter-mobileip can''t be done without also reviewing aaa-key.
' added by Thomas Narten

[Note]: '2004-03-06: AD review has identified some issues that need to be fixed. Once new ID is out, IETF LC, and then to IESG. Note: draft-ietf-aaa-diameter-mobileip-16.txt is waiting on this document; a security review of diameter-mobileip can''t be done without also reviewing aaa-key' added by Thomas Narten

[Note]: '2004-03-06: -04 is out, ready for IETF LC!  Note: draft-ietf-aaa-diameter-mobileip-16.txt is waiting on this document; a security review of diameter-mobileip can''t be done without also reviewing aaa-key' added by Thomas Narten

From: Thomas Narten
To: Pete McCann
cc: "Margaret Wasserman" ,
    "Henrik Levkowetz" , charles.perkins@nokia.com,
    tom.hiller@lucent.com
Date: Sat, 06 Mar 2004 10:23:27 +0900
Subject: Re: Request to advance draft-ietf-mip4-aaa-key-03.txt

OK, I've gone back and completed my review comments for this
document. This takes into account the hallway conversations we had
this week. These are all essentially editorial, i.e., trying to
improve readability and clarify/simplify the IANA stuff.

It would be good to try and get a revised document out quickly. I'll
start IETF LC once we have a rev. Also, the diameter-mobileip document
is stuck in the IESG waiting  for this one. The Security ADs couldn't
review that one without seeing this document.

Thomas


>    It is also assumed that the AAA entities involved (i.e., the AAAH,
>    AAAL, and the AAA interface features of the foreign agents and home
>    agents) all have means outside of the scope of this document for
>    exchanging keys.  The extensions within this document are intended to
>    work with any AAA protocol suite that allows for such key exchange,
>    as long as it satisfies the requirements specified in RFC 2977 [7].

We should probably cite the diameter-mobile IP spec here (as an
example, not normative) now.

                    addresses and an SPI. Two nodes may have one or more
                    Mobility Security Associations; however, typically
                    there is no reason to have more than one Mobility
                    Security Association between two nodes.

Except for rekeying??

>      Registration Key
>                    A key used in the Mobility Security Association
>                    between a mobile node and a foreign agent.  A
>                    registration key is typically only used once or
>                    a very few times, and only for the purposes of
>                    verifying a small volume of Authentication data.

Would it be useful to insert "MN-FA" in front of "Mobility Security
Assocciation", since in this case its the MN-FA one? I note that the
document doesn't currently seem to use MN-FA MSA. It might be good to
use MN-FA or MN-HA whenever you use MSA of a specific type (I found
one such occurrance).

>    The example that follows makes use of HMAC-MD5 [8].  All mobile nodes
>    and mobility agents implementing Mobile IP [13] and implementing the
>    extensions specified in this document MUST implement HMAC-MD5 [13].
>    Other cryptographic functions MAY also be used.

Shouldn't we skip HMAC-MD5 and just require HMAC-SHA1? I.e, HMAC-MD5
has weaknesses. We shouldn't be using it for new things, though it's
not so broken that we need to stop using where it is already deployed.

document would really benefit from some short hand names for the
extensions... E.g.,

>      6.1. Generalized MN-FA Key Generation Nonce Request Extension    9

MN-FA-KeyGen Request

>      6.2. Generalized MN-FA Key Generation Nonce Reply Extension  .  10

MN-FA-KeyGen Reply

>      6.3. Generalized MN-HA Key Generation Nonce Request Extension    11

MN-HA-KeyGen Request

>      6.4. Generalized MN-HA Key Generation Nonce Reply Extension  .  12

MN-HA-KeyGen  Reply

And then use shorthand throughout the document (it's really hard to
parse the full name when one is reading sentences...)

Also,

> 6. Generalized Key Request/Reply Extensions
>
>    The extensions in this section are Generalized Extensions [13], and
>    have subtypes as specified in section 7.

There is no "Generalized Extension" (proper name). RFC 3344 talks
about just Extensions. Better wording would be:

      6. Key Generation Extensions

      The extensions in this section are Extensions as defined in
      [13], and are carried in Registration Request and Reply messages
      defined in [13].


>      Subtype          a number assigned to identify the way in
>                        which the MN-FA Key Generation Nonce Request
>                        Subtype Data is to be used when generating the
>                        registration key

I find it a bit less clear than ideal to not mention the subtype in
the Extension where it is used. I could see splitting out the sub-type
if there were several of them, but there aren't. So, I'd suggest
simply moving some text around from section 7 to the section 6.

E.g.,

> 7. Key Request/Reply Subtypes
>
>    The extension subtypes in this section are subtypes of the
>    Generalized Extensions specified in section 6.

we don't even need this I think...

> 7.1. MN-FA Key Generation Nonce From AAA Request Subtype
>
>    The MN-FA Key Generation Nonce From AAA Request subtype data uses
>    subtype 7 of the Generalized MN-FA Key Generation Nonce Request
>    Extension (see section 6.1).  The MN-FA Key Generation Nonce From AAA
>    Request extension MUST appear in the Registration Request before the
>    MN-AAA Authentication extension.  The subtype data field is zero in
>    length.

In section 6.1, just say the subtype is 7. No need to mention that
there is a zero-length data field. (and does it _really_ need to be 7?
If this is not in real deployment, can't we just use 1 for all the
subtypes and start fresh?  Note: how can actual the subtype value
matter since you have TBDs for the extension type... )

For 7.2, make it a subsection of 6.2, e.g, 6.2.1? The two sections go
together and it's hard to understand the Extension without looking at
this subtype.

Sections 7.3 and 7.4 can be done similarly.

Note: any future document that uses a different subtype, will need to
define the specific behavior for how each sub-type is used, so I'm not
really sure that putting the sub-type stuff in its own section is
really all that helpful.

For the IANA considerations section, here is what I'd suggest for the
subtype stuff (note, I'm guessing here a bit about what makes sense
based on my understanding of the various conversations in
Seoul. Correct me if I've got it wrong.) Change:

>    The numbers for the Generalized Extensions in section 6 are
>    taken from the numbering space defined for Mobile IP registration
>    extensions defined in RFC 3344 [13] as extended in RFC 2356 [11].
>
>    IANA will create and maintain a namespace for the subtypes associated
>    with each Generalized Key Generation Nonce Request/Reply Extension.
>    The numbers suggested in this section are already in use by
>    implementations which have been tested for interoperability.
>
>    The number 7, assigned to the MN-FA Key Generation Nonce From AAA
>    Request Subtype extension, is taken from the numbering space defined
>    for the Generalized MN-FA Key Generation Nonce Request Extension (see
>    section 6.1).
>
>    The number 1, assigned to the MN-FA Key Generation Nonce From AAA
>    Subtype extension, is taken from the numbering space defined for
>    the Generalized MN-FA Key Generation Nonce Reply Extension (see
>    section 6.2).
>
>    The number 7, assigned to the MN-HA Key Generation Nonce From AAA
>    Request Subtype extension, is taken from the numbering space defined
>    for the Generalized MN-HA Key Generation Nonce Request Extension (see
>    section 6.3).
>
>    The number 7, assigned to the MN-HA Key Generation Nonce From AAA
>    Subtype extension, is taken from the numbering space defined for
>    the Generalized MN-HA Key Generation Nonce Reply Extension (see
>    section 6.4).

To something like:

  This document defines 4 new extensions (see Section 6) taken from
  the (non-skippable) numbering space defined for Mobile IP
  registration extensions defined in RFC 3344 [13] as extended in RFC
  2356 [11]. The values for these extensions are:

  Name Value
  MN-FA-KeyGen Request TBD1
  MN-FA-KeyGen Reply TBD2
  MN-HA-KeyGen Request TBD3
  MN-HA-KeyGen  Reply TBD4

[and change the earlier TBDs in the document to TBD1, etc. to make it
clear they are all different.]

  IANA will create and maintain a two new registries, one for MN-HA
  KeyGen Subtypes, the other for MN-FA KeyGen subtypes. The initial
  contents of the MN-HA KeyGen subtype registry is:

    [fill it in.]

  The initial contents of the MN-HA KeyGen subtype registry is:

    [fill it in]
   
    New subtypes for these two registries are assigned through
    Standards Action as defined in [RFC 2434].

[note: is that the right allocation policy? My guess is you don't want
to assign subtypes without some pretty good review by the WG or its
heirs since this is a security issue.]

Finally, which algorithms are mandatory-to-implement? [this question
is moot if you do away with HMAC-MD5, since there then is only one
listed.]

[Note]: '2004-03-06: AD review has identified some issues that need to be fixed. Once new ID is out, IETF LC, and then to IESG. Note: draft-ietf-aaa-diameter-mobileip-16.txt is waiting on this document; a security review of diameter-mobileip can''t be done without also reviewing aaa-key' added by Thomas Narten

[Note]: '2004-03-06: AD review has identified some issues that need to be fixed. Once new ID is out, IETF LC, and then to IESG.

Note: draft-ietf-aaa-diameter-mobileip-16.txt is waiting on this document; a security review of diameter-mobileip can''t be done without also reviewing aaa-key' added by Thomas Narten