[Mip4] AD review of draft-ietf-mobileip-aaa-key-13.txt

Here are my review comments. Overall, I think the document is in
pretty good shape, but some wording clarifications would be
good. Also, more analysis of the security weaknesses is probably
warranted.

Thomas

Substantative:

>       AAA security association
>                     A security association between a AAA entity
>                     and another node needing the services of that
>                     AAA entity.  In this document all AAA security
>                     associations are between a mobile node and its home
>                     AAA server (AAAH). A mobile node's AAA security
>                     association with its home AAA server (AAAH) may be
>                     based either on the mobile node's IP address or on
>                     its NAI [1].

Could be more clear.

In particular (based on later reading), the AAA association appears to
consist of a name for it (i.e, the SPI plus addresses so that peers
can agree on what AAA SA is being referred to) plus a key. The key of
some size (used in Section 5).  Is there anything else that is
contained in this SA? It would be good to just state that the it is
simply a shared symetric key.

>       Mobility security association
>                     A Mobility Security Association is a simplex
>                     connection that serves to authenticate MIPv4 control
>                     traffic such as between a MN and HA and/or a MN and
>                     FA. A Mobility Security Association is identified
>                     by the two end points, such as a MN IP address and
>                     a HA IP address, and a SPI. Two nodes may have one
>                     or more Mobility Security Associations established
>                     between each other; however, typically there is
>                     no reason to have more than one Mobility Security
>                     Association between two nodes.

I.e., suggested rewording (and corrections, if I understand
correctly):

      Mobility security association

                A Mobility Security Association is a bi-directional
                connection that applies security services to RFC 3344
                MIPv4 control traffic between a MN and HA (or MN and
                FA) using RFC 3344 Authentication Extensions.  A
                Mobility Security Association is uniquely identified
                by the peer source and destination IP addresses and an
                SPI. Two nodes may have one or more Mobility Security
                Associations established between each other; however,
                typically there is no reason to have more than one
                Mobility Security Association between two nodes.

>       Registration Key
>                     A key used as the basis of a 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.

don't understand first sentence.

Is Registration Key actually the key in the AAA Security Association?
If so, better to just say so.

>     2. If the mobile node does not have a Mobility Security Association
>        with the home agent, it MUST add an MN-HA Key Request extension
>        (see Section 7.3) as part of its Registration Request that it
>        sends to the Foreign Agent.

Is there no other way for the MN to set up the MN-HA key other than
via AAA? (Seems like the MUST is a bit strong.)

>     1. Using the Key Material from the extension, the mobile node
>        calculates
> 
>           key = HMAC-MD5 (AAA-key, {Key Material || home address})

what is AAA-key? Is this the key that is part of the AAA SA? Would be
good to define this better (e.g, define a term, and use the term
consistently). Also, does this key have any particular length or other
properties?

>       MN-FA Key Request Subtype Data
>                        Data needed to carry out the creation of the
>                        registration key on behalf of the mobile node.
>                        This field is zero in length and carries no data.

Would be better to have this field have the same name as is used in
(say) section 5, where "Key Material" is used. Can we define a proper
name for this field?

Actually, why do you have this field at all, when it is defined to
have zero lengh and carry no data?

Security considerations seems pretty weak. Where is the analysis of
the weaknesses/vulnerabilities in the system? I.e, nothing is said
about how keys are distributed within the AAA and how if that is weak,
how it might result in compromise of the AAA key...

>    One further detail deserves mention.  The Mobility Security
>    Association to be established between the mobile node and the foreign
>    agent have to be communicated to the foreign agent as well as to the
>    mobile node.  The way that the key is distributed to the foreign
>    agent is not relevant to any material in this document, and is
>    expected to be handled as part of the AAA protocol processing between
>    the AAAH and AAAL, and the further AAA protocol processing between
>    the AAAL and the foreign agent.  Any method by which the key can be
>    securely transmitted to the AAAL and then relayed (possibly with
>    re-encryption) to the foreign agent, is outside the jurisdiction
>    of any Mobile IP specification, and thus compatible (by reason of
>    non-interference) with the protocol extensions specified in this
>    document.

Note: the above is not quite true. To understand the weaknesses of the
proposed extensions, one has to make assumptions about the above. I.e,
is the AAA SA key actually communicated to the FA via AAA? If so,
there are huge potential vulnerabilities here (one can't just assume
the AAA protocols are secure enough to not worry about this). I.e, is
there an assumption that the AAA Key itself will be communicated  from
the AAAH to AAAL (and the FA?).

Nits:

Could use a TOC (see ID nits, http://www.ietf.org/ID-nits.html)

>                  AAA Registration Keys for Mobile IP

title doesn't satisfy ID nits? (Not sure AAA will be acceptable to rfc
editor).

>   the Authentication Data need by authentication extensions used in

s/need/needed/ ?

>    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

AAAH and AAAL not defined/expanded in first use.

>    The key material may be requested by the mobile node in new
>    extensions to Mobile IP Registration Request messages, and supplied
>    to the mobile node in extensions to the Mobile IP Registration Reply
>    messages.  Alternatively, the AAA server MAY provide unsolicited key

s/new extensions/new extensions (defined below)/

>    messages.  Alternatively, the AAA server MAY provide unsolicited key
>    material to mobile nodes; the mobile node MUST then calculate new

s/material/material via mobility agents/

>     8. If a MN-HA Key Material from AAA Key Material extension is
>        present in the Registration Reply message, then the mobile node
>        MUST create or update its Mobility Security Association with the
>        Home Agent indicated in the Registration Reply, using the key
>        computed from the Key Material in the AAA extension.  In this
>        case, if no Key Material extension is present, the mobile node
>        MUST discard the Registration Reply.  If the mobile node does
>        not already have a Mobility Security Association with the Home
>        Agent indicated in the Registration Reply message, and if no Key
>        Material extension is present, the mobile node MUST discard the
>        Registration Reply.
> 

Is this last sentence needed? There is an AND in the if. But one o
the ANDs is already covered bythe previous sentence (I think), in
which case the RR is already supposed to be discarded.

>   The following steps are performed on the AAA server:

AAAL or AAAH? (I assume the former).

>     2. The mobile node creates the Mobility Security Association, using
>        the key and the other relevant information in the Key Extension.
> 

which MSA? the one to the HA or the one to the FA?

>    The Generalized MN-FA Key Reply extension supplies a registration key
>    requested by using one of the subtypes of the Generalized MN-FA Key

not a "registration key", but "keying material"

>       MN-FA Key Reply Subtype Data
>                  An encoded copy of the registration key, along with any
>                  other information needed by the recipient to create the
>                  designated Mobility Security Association.

needs better text; this is not a key, its keying material. (do the
same throughout document)

>    If the foreign agent receives a Registration Reply that has no MN-FA
>    Key Reply extension, and if it has no existing Mobility Security
>    Association with the mobile node, the foreign agent MAY change
>    the Code value of the Registration Reply to MISSING_MN_FA (see
>    section 8), effectively causing the registration to fail.

Is this a typo? I thought the MN would get the RR, not the FA. How is
the FA getting this?

> 6.1. Generalized MN-FA Key Request Extension

Note: It would seem to be better to rename this extension to be "Key
Material" request or something, as this is NOT requesting a Key per
se.

IANA Considerations:

>    The Code value specified for error MISSING_MN_FA, listed in
>    section 8, MUST NOT conflict with any other code values listed in
>    RFC 3344, RFC 3024 [10], or RFC 2356 [11].  This value is to be
>    taken from the space of error values conventionally associated with
>    rejection by the foreign agent (i.e., 64-127).

Above doesn't  quite make sense in IANA considerations. IANA doens't
assign values that have already been assigned for other purposes. Or
rather, they only do so if folks have just used a number for some
purpose without bothering to allocate it properly from IANA. So, the
above paragraph should be reworded to just say IANA assigns a TBD, and
if there is a recommended value, suggest what it is). I.e, does the WG
know more than IANA about the code values that are already in use?

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

Better to use words like: IANA will create and maintain namespace for
Replay Method Identifier as defined in Section 4. This
specification...

In appendix C, I think you want to use a term other than "IP Security
Association". First, its a term that is not defined. Second, it can be
read to mean IPsec SAs, which I suspect is not actually the case.

_______________________________________________
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4