Subject: [mobile-ip] IESG feedback on AAA keys doc

From: Phil Roberts <[email-masked]>
Date: Thu, 30 Aug 2001 14:45:58 -0400

Hi folks,

    IESG feedback on this one.

Phil
------------------------------

This is a comment that probably applies to lots of MIP
documents. Please define "security association" in the MIP context. In
IPsec terminology, for instance, it means something very
specific. I.e., keys, SPIs, etc., and works only between a pair of
nodes. Once an association exists, encrypted packets can be sent. No
further negotiation is needed. Also, one can have multiple (different
SAs between the same set of machines). This document says:

   node and its home agent.  When the mobile node shares a security
   association with its home AAA server, however, it is possible to use
   that security association to create derivative security associations
   between the mobile node and its home agent, and again between the
   mobile node and the foreign agent currently offering connectivity to
   the mobile node.  This document specifies extensions to the Mobile

The MN talks to its HA, not a AAA server. So I'm not clear what is
meant by "shares a security association". From my perspective, it
seems like "security relationship" would be more accurate terminology.

Note that the above paragraph also talks about "security associations"
between the MN and HA. Here, the terminology  (I suspect) corresponds
more closely to the IPsec usage. But I'm not sure. 

General comment. This document is very loose about whether a MN is
talking to a FA/HA or a AAA server. This should be made explicitly
clear throughout. Indeed, my assumption is that conceptually, if not
in reality, a MN NEVER speaks to an AAA server directly. Rather, it
speaks MIP protocols with an HA/FA, and that HA/FA has a side
conversation with the AAA server. This should be made much more clear
throughout.

> 2. Scope of Protocol
> 
>    The protocol and messages in this document are intended to facilitate
>    the following operations which may occur between the mobile node, AAA
>    server, home agent, and foreign agent.

Throughout this section, it should be made explicitly clear *who* is
sending a message, and *to* *whom* the message is being sent. Also,
when someone processes an extension *who* is doing the
processing. This isn't clear from just reading the text.

Also, it might make sense to change the section heading to "overview"
rather than Scope, since it does seem like an overview. Assuming this
is an overview, I think it would help the reader if the text included
steps such as as "FA sends message to AAA server ..." "AAA server does
X and returns Y to the FA", "FA generates reply and sends to MN"... 
   
    2. If the mobile node does not have a Mobility Security Association
       with the foreign agent, it SHOULD include an MN-FA Key Request
       extension.

In what message, and sent to whom?

What is the RFC reference to the key request extension?

    3. Similarly, if the mobile node does not have a Mobility Security
       Association with the home agent, it MUST add an MN-HA Key Request
       extension.

In message sent to whom?

    4. If one or more Key Request extensions were added, the MN-AAA
       Authentication extension is added to the Registration Request.

Added by whom?
       
    5. At the time the information within the MN-AAA Authentication
       extension is verified by the AAA server, the AAA server also
       generates Key Material for the keys requested by the mobile node,
       and causes insertion of the Key Material fields along with the
       Registration Reply.

So there is an implied step here in which the FA exchanges messages
with its local AAA server? Would be good to explicitely say that here.

Is that AAA protocol already in place? What RFCs are used? I.e, is
there a potential normative reference problem buried here? (I suspect
the answer is no, but am not sure.)

    6. The respective AAA keys are distributed to the Home and Foreign
       Agent via the AAA protocol.

Where are the details of this described?

step 6b) FA sends a reply to the MN

>    extension.  In order for the mobile node to make use of key
>    information sent to it by the AAA server, the mobile node also has to
>    be able to select the appropriate cryptographic algorithm that uses
>    the key to produce the authentication.  The following table contains

I doubt the AAA server is sending messages to the MN. Isn't it the FA
that does this (i.e., it relays this info)? Text could be more
precise.

   Dynamic Mobility Security Associations shared between mobile nodes

What is a "Dynamic Mobility Security Association"? Is it different
than other types of security associations?

Note: IMO, it would be better to move the description formats of the
extensions here, rather than at the end. It is a bit confusing to talk
about the contents of packet fields prior to having shown the format
of the option with all of the fields together.

> 4. Key Material Creation and Derivation
> 
>    This section contains the procedures followed in the creation of the
>    Key Material by AAA servers, and the key derivation procedures used
			        ^
>    by mobile nodes.  Note that the AAA servers will also make use of the

insert "extension" as indicated above? Also, better to say "contains
the procedure a FA/HA follows when creating ..." (or is the procedure
aimed at AAA servers?)
   
   The example that follows makes use of MD5 in prefix+suffix mode,
   whose support is mandatory in Mobile IP [11].  Other cryptographic
   functions, such as those listed in 3 MAY also be used.

Might be better to make HMAC-MD5 the example. Also, what is meant be
"listed in 3 MAY". Should that be "listed in [3] MAY"??

    1. The AAA server identifies the mobile node's via a
       ``node-address''.  If the Home Address field of the
       Registration Request is zero (0), the Mobile Node's NAI is used
       instead.

First sentence doesn't parse.

I'm confused by the description above in the sense that it implies
that the MN Registration Request is sent to a AAA server. I thought it
was sent to a FA.

Also, why use the term "node-address"? Don't you really mean the home
address? (the term node-address isn't defined anywhere). Maybe you
mean to say:

    1. The AAA server identifies the mobile node via a
       ``node-address''.  The node-address is taken from the Home
       Address field of the Registration Request, or the NAI, if the
       Home Address field is zero (0).

Note again how the text blurs the distinction between the FA and the
AAA server. Does the AAA server see the registration request? I would
think not. It sees information the FA sends to it, which includes
portions of the registration request. The document should really make
this clear throughout

>    2. The AAA server generates a random [5] value of at least 64 bits.

64 bits seems short. I'd like someone with security background to
comment on this. But I guess this is sent in the clear, so the length
may not matter?

    3. The AAA server inserts the random value into the Key extension in
       the ``Key Material'' field.

Presumably this field is part of a message or an extension within a
message. Which message or extension? Make explicit.

Note steps 1-3 are done on the server, steps 4-5 on the mobile
node. It might be good to make the more clear here, perhaps by having
subsections?

    4. The mobile node calculates

          key = MD5(AAA-key | Key Material | node-address | AAA-key)

what is AAA-key? Where does it come from? Ditto for "Key Material" How
does the mobile node know which AAA-key to use? Can there only be one
(I hope not...)

      Key Material
                 A random [5] value of at least 64 bits.

Keying material of only 64 bits? Would this pass security muster??

>       AAA SPI    A 32-bit opaque value, indicating the SPI that the
>                  mobile node must use to determine the algorithm to use
>                  for establishing the FA security information.

How does the mobile node create this SPI? Is this preconfigured?

>       FA SPI     A 32-bit opaque value, which the mobile node MUST use
>                  to index all the necessary information established for
>                  the FA security information after it is decoded.

Might be better to say something like:

       FA SPI     The SPI for the Security Association to the FA that
                  the MN creates as a result of processing this extension.

>       Algorithm Identifier
>                  This field indicates the algorithm to be used for
>                  future computations of the MN-FA Authentication
>                  Extension (see section 3)

It would be good to state explicitely state that this is the same
algorithm identifier as defined in XXX (section 3 doesn't seem to do
this either). This document doesn't say. I.e., this presumably points
to an existing name space managed by IANA. What is it? [hmm I later
see that this is a new name space.. see comment below.]

>    The Unsolicited MN-FA Key Material From AAA extension, shown
>    in figure 1, uses subtype 7 of the Generalized MN-FA Key Reply
>    Extension [12].  

Shouldn't this be moved to the beginning of section 5. (e.g., as it is
in Section 6?)

>       HA SPI     A 32-bit opaque value, which the mobile node MUST use
>                  to index all the necessary information established for
>                  the HA security information after it is decoded.

Same comment as above w.r.t FA SPI. Ditto for key material.

>    the Key Material provided by the home domain AAA server (AAAH). The
>    key is intended for use the mobile node to secure future Mobile IP
>    registrations with its home agent.  The MN-HA Key Reply MUST appear

sentence doesn't parse.

>    The mobile node uses the Identification field data from the
>    Registration Request as its initial synchronization data with the
>    home agent.

What is the field referred to in this sentence?

> 7. MN-FA Key Request From AAA Subtype
> 
>    The MN-FA Key Request From AAA subtype data uses subtype 7 of the
>    Generalized MN-FA Key Request Extension [12].  The MN-FA Key Request
>    From AAA extension MUST appear in the Registration Request before the
>    MN-AAA Authentication extension.  The subtype data field is zero in
>    length.
> 
> 
> 8. MN-HA Key Request From AAA Subtype
> 
>    The MN-HA Key Request From AAA subtype data uses subtype 7 of the
>    Generalized MN-HA Key Request Extension [12].  The MN-HA Key Request
>    From AAA extension MUST appear in the Registration Request before the
>    MN-AAA Authentication extension.  The subtype data field is zero in
>    length.

Hmm. What are the above two sections about? The first sentence in each
seems redundent. Can't the remaining text just be put in the previous
sections that describe the extension?

Also, why is the ordering important? 

> 10. IANA Considerations

This document requests certain numbers be assigned. Is this required,
i.e., are their implementations that already use the numbers? This
section should really say TBD for any assignments that it  doesn't
care what the  actual value is, and let IANA pick. If it really does
care about the value, the text should suggest a certain value be used
and mention that the numbers are already in use by existing
implementations. That way, IANA has some context for deciding what to
do.

>    Section 3 introduces the Algorithm Identifier namespace that requires
>    IANA management.  This specification makes use of 1-3; all other
>    values other than zero (0) are available for assignment, pending
>    review and approval by a Designated Expert [9].

Can't you just leverage off an existing MIP name space (i.e, the one
used by other extensions?) rather than creating a new one?