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

From: Phil Roberts <[email-masked]>
Date: Fri, 23 May 2003 10:19:04 -0400

Folks,
 
      this is a very brief WG last call for the AAA Keys draft.  WG last
call was completed on this draft quite some time ago.  Last spring it
received a security review.  All comments from both the security review and
the last call have been addressed and the terminology section
has been revised.  But because the last call was completed so long ago we
are issuing a brief WG last call.  Please post any last call
comments you have to the mailing list by Friday, May 30.
 
 <http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-key-12.txt>
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-key-12.txt
 
Thanks,
Phil

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Wed, 28 May 2003 06:35:30 +0900

Chair,  Thank you for this opportunity of the second last call.
Thanks. -Yoshi

Hello Charlie and Pat,

 I've found one issue at the following step-1 in the section 5:
>>  1. The AAA server identifies the mobile node.  If the Home Address
>>       field of the Registration Request is either zero (0), or all ones
>>       (0xffffffff), then the Mobile Node's NAI is used instead of the
>>       mobile node's home address.

 - Does the above step imply the Home Address is used as the ID of an
   MN, instead of NAI, if it is neither zero nor all ones, too ?
 - Also, does the above mean the Home Address field should be either
   zero or all ones, if an MN wishes to be identified by NAI ?

 If possible, I'd prefer always identified by NAI simply.  Actually, in the
 following two scenario, an MN would like to set its home address in RRQ,
 but would like to be identified by NAI, when it gets home address dynamically
 by such as "Mobile IP Agents as DHCP proxy":

 a) In case an MN wants to get an MN-FA key only, when it moves to a
    new visited subnet from a visited subnet.
 b) In case an MN wants to get both an MN-HA key and an MN-FA key,
    but it has already got its home address in the home subnet, when it
    firstly moves to a visited subnet from its home subnet.  In the home
    subnet it may get an MN-HA key, but it may be cleared by deregistration.
    Thus, it need to request two keys again , when it firstly moves to a
    visited subnet from its home subnet.

Thanks in advance.
-Yoshi

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 May 2003 14:35:38 -0700

Hello Yoshi,

>    MN, instead of NAI, if it is neither zero nor all ones, too ?

No.  The home address is always used as just the home address
when it is valid for that purpose.  The home agent uses the home
address for identifying the mobile node.

The NAI is used by the verification infrastructure to identify
the mobile node, in cases where the mobile device supplies the
proper sort of authentication extension for that operation.

>    zero or all ones, if an MN wishes to be identified by NAI ?

No, because then the home agent won't be able to route to the
mobile node.

>  If possible, I'd prefer always identified by NAI simply.

This is certainly a possibility in any system you may wish to build.

>                                                          Actually, in the
>  but would like to be identified by NAI,

Which entity is performing the identification?

>                                         when it gets home address dynamically

Why would deregistration clear the MN-HA key?  It seems to me that
the keys ought to last a lot longer than a single registration time.
But you can make it as dynamic as you like!

Regards,
Charlie P.

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Wed, 28 May 2003 17:10:45 +0900

Hello Charlie,

 Thank you for your prompt response.  It helped my
 understanding greatly.  My comments are inlined:

>proper sort of authentication extension for that operation.

 Thank you for your qualification.  I could understood correctly.
 At the first time when I read those texts, I misunderstood that
 the second sentence wasn't about HA, but about AAA server.

>No, because then the home agent won't be able to route to the

 OK, this question was due to my misunderstanding.

>Which entity is performing the identification?

 I mean; it's an AAA server.

>But you can make it as dynamic as you like!

 You know, an HA doesn't play any role after deregistration, while an
 MN stays at home subnet.  So, I thought, an HA could recover resource
 by clearing MN-HA key and so on, as soon as deregistration, instead of
 waiting for lifetime expiration.  But, I agreed it could be achieved by
 other ways.

Best regards.
-Yoshi

---

From: Alpesh <[email-masked]>
Date: Thu, 29 May 2003 10:02:01 -0700

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?

#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?

#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.

#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).

#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.

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.

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?

     (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.

Thanks
Alpesh

---

From: Alpesh <[email-masked]>
Date: Fri, 30 May 2003 10:02:03 -0700

Reposting ...

Alpesh wrote:

>       AAA for bidirectional authentication? Since this is a framework, 
> I prefer to
>       extension is located in Registration Request - before or After 
> the MN-AAA AE.
>       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.
>
> AAA infrastructure, some references are very Diameter specific. In 
> cases where

---

From: Milind Kulkarni <[email-masked]>
Date: Fri, 30 May 2003 10:12:49 -0700

Great job Alpesh. Keep up the pressure.

Milind

---

From: Kuntal Chowdhury <[email-masked]>
Date: Fri, 30 May 2003 17:07:24 -0500

I think the draft needs a clear demarcation between types of AAA (DIAMETER and 
RADIUS). For example the following may be possible with DIAMETER but may not be 
possible with RADIUS. It is not clear who added the MN-HA AE in the RRP for a 
RADIUS AAA scenario.

Section 3.
"    9. Using its (perhaps newly created) Mobility Security Association
        with the home agent, the mobile node authenticates the
        Registration Reply message, by checking the Authentication Data
        in the Mobile-Home Authentication extension.
"

-Kuntal

Alpesh wrote:
>>              Again, this statement implies that AAA server is 
>> constructing the extensions in