Subject: Re: [mobile-ip] WG Last Call: AAA Keys

From: Charlie Perkins <[email-masked]>
Date: Sun, 01 Jun 2003 22:03:35 -0700

Hello Alpesh,

Alpesh wrote:

> Charlie and Pat:
>
> I have a few questions that I posted sometime in November 2002, which were
> pending due to the v6 prioritization. Would appreciate if you can 
> address these
> doubts/concerns:
>
> #1. Section 6.4 Generalized MN-HA Key Reply Extension includes
>      'Lifetime' field (not included in section 7.4 MN-HA Key Material 
> from AAA Subtype).
>
>     On the contrary, for MN-FA dynamic key, Section 6.2 Generalized 
> MN-FA Key
>      Reply Extension does not include 'lifetime'. 'Lifetime' field is 
> included in
>      section 7.2 MN-FA Key Material From AAA subtype.
>
>    Wondering why this is asymmetric?

A subtype of the MN-FA Key Reply extension _could_ include a lifetime
if need be,  but there are realistic scenarios (perhaps even the common 
case)
where the key would expire as soon as the mobile node moves away.
This is not true for the home MN-HA key, thus the asymmetry.

> #2. Section 1, 4th paragraph states ....
>        "    connection to the foreign domain, without having any home 
> address.
>    However, for Mobile IP to work, the mobile node is required to have a
>    home address and a Mobility Security Association [13] with its home
>    agent.  When the Mobile IP Registration Reply packet is authenticated
>    by the MN-AAA Authentication Extension [4], the mobile node can
>    verify that the key material contained in the extensions were
>    produced by the AAA server, and thus may be reliably used to create
>    Mobility Security Associations with the home agent, or alternatively
>    with the foreign agent. "
>
>    It implies that the MN-AAA Authentication Extension is present in 
> Registration
>    Reply. Maybe the wording should have been - MN-HA Authentication
>    Extension?

No, this is right, because the mobile node may not yet know the MN-HA
key.

> #3. With Key Generation, the MN-AAA AE is present and MHAE is
>     unlikely to be present. Can we add a note that MHAE is 'optional' when
>      Registration Request contains key generation extensions and 
> MN-AAA AE?
>      Either this draft for 3012bis should probably make a note of this 
> point.

This would be fine with me.

> #4. The Generalized MN-FA key request extension and Generalized MN-HA
>       Key request extension includes  the corresponding Subtype Data. 
> The draft
>       explicitly spells out that in both cases, the Subtype Data have 
> "zero length".
>        When the Length field is present in the Key Request Extension, 
> why put such
>       a restriction? Probably the Subtype Data can carry a "challenge" 
> from MN to
>       AAA for bidirectional authentication? Since this is a framework, 
> I prefer to
>       see it flexible where possible (without making the specification 
> vague).

Presumably, this would be done by a different subtype.  It would certainly
need more specification.

> #5. Just to clarify, can you make a note about where the MN-FA Key Request
>       extension is located in Registration Request - before or After 
> the MN-AAA AE.
>       Currently this is not clear - if located before the MN-AAA AE, 
> then FA
>       cannot strip this extension before forwarding Registration 
> Request to the HA.
>       If located after the MN-AAA AE, then it is not authenticated, 
> but can be stripped.

I thought the key request extension should precede the MN-AAA extension.
Anyway, I'm not particular one way or the other, and I don't know that there
has to be a restriction one way or the other.  Mobile IP doesn't necessarily
impose a strict ordering for every possible combination of extensions.

> While the draft clearly mentions that the document is generic for any 
> suitable
> AAA infrastructure, some references are very Diameter specific. In 
> cases where
>  the draft is Diameter specific, it should say so. To point a few 
> examples:
>
> 1. Section 3, 2nd paragraph states ... " Alternatively, the AAA server 
> MAY provide
>     unsolicited key
>    material to mobile nodes; the mobile node MUST then calculate new
>    keys and update or create its relevant Mobility Security Association."
>
>     This unsolicited key material delivery seems to be very Diameter 
> specific.

The draft cannot cite Diameter, because that would be a normative reference.
As it is, some other AAA protocol may also be specified and would then be
able to satisfy the requirement equally well.

> 2. Section 5: Key Material Creation and Derivation
>
>     The text under "The following steps are performed on the AAA server"
>
>     steps 1 and 3 seem to be Diameter specific:
>
>     (1): mentions that AAA sees Registration Request and the 
> home-address/NAI. Can we
>      just state that the Mobile Node can be identified by the Home-Address
>      or NAI without referring to the Registration Request?

The registration request has the replay protection.

>       (3) AAA server inserts the random value into the Key Reply 
> Extension, in the
>       "Key Material" field.
>      
>         Again, this statement implies that AAA server is constructing 
> the extensions in
>         Registration Reply, which holds for Diameter and not for Radius.

... or some other AAA protocol we don't know yet.

Regards,
Charlie P.