Re: [Mip4] draft on RADIUS support for Mobile IP

[Kent Leung <[e-mail]>]

Hi Madjid et al.,

The draft looks pretty good overall.  Some comments.

1) Please reference draft-ietf-mobileip-rfc3012bis-06.txt in document.

2) Since the User-Name AVP will be populated with MN-NAI or MN-HoA,
     why are the MIP-MN-NAI and MIP-MN-HoA AVPs needed?  If all AVPs
     are supported, then how is the combination of them prioritized for
     user lookup?

3) For CCoA mode Authenticator calculation, refer to 3012bis.  The Challenge
     is non-zero.  The MFCE is part of the RRQ sent from MN to HA.

4) In 3.1 HA process RRQ section, since the NAS-IP and HA-IP addresses
     may be different, shouldn't the MIP-HA-IP address or MIP-HA-NAI always
     be included in the Access-Req?  The NAS-IP and the RADIUS server have
     a shared secret to protect communication between them
     (Message-Authenticator).  The MIP-HA identifier serves a different
     function (e.g. possibly tag for HoA assignment).

5) General comments for clarity on labels.  XXX-REP to XXX-REPLAY,
     XXX-LIFE to XXX-LIFETIME, XXX-ALGID to XXX-ALGORID.

6) Typo in "The HA receives the RADIUS Access Accept" bullet.  Remove
     "using and MN to HA MSAs".

7) Same 3.1 section, "The MN extracts" bullet, specify how the MN-HA key
     is derived (or reference [MIPKEYS]).

8) Figure 2a, label 1, 2, 3, etc. on the flow would be useful.

9) Sect 3.2 "The FA checks" bullet, missing ")" for MIP-FA-IP 
address.  Same issue
     with NAS-IP and MIP-FA-IP address as above.  Should have FA-IP identifier
     (either MIP-FA-IP-address or MIP-FA-NAI) in case HA in foreign network
     assignment happens.  Also, why is the MIP-FA-NAI  added only if HA 
address is
     all 1s or 0s?  The value of MIP-HA-IP-address can be set to HA field 
in RRQ.

10) "The AAAH compares this value" bullet, I think having a new MIP-FA-HA-nonce
      is good to associate the 2 Access-Requests (one from FA, and other 
from HA)
      to set up the FA-HA MSA.  Also, the MIP-MN-FA-nonce is missing in the 
list for
      Access-Request.

11) "The FA retrieves the MN-FA key" bullet, typo "Access-Request" should be
       "Access-Accept".

12) "Upon receiving the reg" bullet, same issue with NAS-IP and MIP-HA 
identifier.
      Also, why are MIP-FA-to-HA-SPI and MIP-FA-HA-Authenticator AVPs included?
      See my opinion below.  May also want to have MIP-MN-FA-NAI as the FA
      identifier to index the MSA.  Another point to capture is the case 
when the
      FA-HA MSA exists (e.g. created by another MN which registered previously
      between the FA and HA).  Then the HA just authenticate the FHAE first
      before sending Access-Request to AAA server.

13) "The AAAH finds the FA-HA MSA" bullet, I think AAA should only be
      responsible to authenticate the MN and provide the keys to the HA, which
      is responsible to authenticate FHAE and MHAE (if there).  So AAA server
      should authenticate MN using the MIP-MN-AAA-SPI and
      MIP-MN-AAA-Authenticator.  Also, if the AAA server receives the 
MIP-FA-HA-nonce,
      it can find the right FA-HA MSA to provide to HA.

14) Same bullet as above, why does the Access-Accept include the MIP-MN-FA-XXX
       AVPs?  These were already delivered to the FA in the RADIUS exchange 
between
       FA and AAAF.

15) "The HA retreives the key materials" bullet, I don't think HA should be 
putting
       MN-FA-nonce.  HA should only put the MN-HA-nonce in the KeyGenReplyExt
       protected by MHAE.

16) "The FA relays the RRP" bullet, I think the FA should put the 
MN-FA-nonce in
       the appended KeyGenReplyExt protected by MFAE before sending to MN.

17) Sect 4.2, "the HA and FA may send their own IP addresses inside NAS-IP
       instead of MIP-[HA|FA]-IP-address".  I think the MIP-[HA|FA] 
identifiers should
       always be in the Access Req.

18) Sect 5, MIP-HA-IP address, why "the FA this attribute MAY not be used in
       the Access-Request"?  The HA address could be helpful to for setting 
up FA-HA
       MSA.

19) MIP-MN-AAA-SPI, String should be unsigned32 and Length should be 6.

20) Mobile IPv4 feature vector, if mapping to DIAMETER, then this should be 
unsigned32.
      The "8-bit flag vector" should be called "bitflag vector" as current 
allocation is already
      over 8 bits.  :)  Length would be 6.

21) Why bit 8 Foreign-Home-Agent-Available not supported?  This could be set by
       FA to notify to AAAH that AAAL can assign the HA when relaying the 
Access-Accept.
       I'm not clear on usage of bit 2 
Home-Address-Allocatable-Only-in-Home-Realm.
       Also, I'm not sure why we don't have bitflag to indicate if the 
Access-Request is
       sent by FA or HA?  That might clarify some operations on the AAA server?
       Let's say the Access-Request contains the NAS-IP for authentication 
between NAS
       and AAA server and FA and HA identifiers to set up MSA, shouldn't 
AAA need to
       know which is FA or HA to set up the directional SPI for MSA?

22) MIP-MN-to-HA SPI and MIP-HA-to-MN-SPI , String should be unsigned32 and 
length is 6.

23) MIP-MN-HA-ALGID, not clear how algorithm identifier is mapped?  We have 
keyed MD5
       and HMAC-MD5.  Having a string doesn't make sense.  Maybe unsigned8 
and specify
       1 for keyed MD5 and 2 for HMAC-MD5?

24) MIP-MN-HA-REP, same issue with string.  Maybe unsigned8 and specifiy 1 for
       timestamp (with field for replay range) and 2 for nonce?

25) MIP-MN-HA-MSA-LIFE, integer should be unsigned32 and length is 
6.  Should we
      allow 0xFFFFFFFF to mean infinite lifetime for MSA?  This means the 
MSA remains
      for lifetime of one registration session (MSA deleted when 
registration ends).

26) Remove bunch of AVPs above the format of FA to HA SPI.

27) FA to HA SPI and HA to FA SPI, string is unsigned32 and length is 6.

28) Would like to add new MIP-FA-HA-nonce AVP.

29) In 5.1, attribute list is missing MIP-FA-NAI, MIP-MN-HA SPI and 
MIP-HA-to-MN-SPI
       should change "HA" to "FA" before "Encrypted", missing 
Encrypted[MIP-MN-FA-key],
       new MIP-FA-HA-nonce, duplicate MIP-MN-HA-MSA-LIFE.

30) Sect 8, "We recommend that the AAAH also authenticates the nonce reply
      extensions with the AAA SA it shares with the MN".  This is for MITM 
attack for
      msg from AAAH to HA/FA.  Doesn't the Message-Authenticator protect 
tampering
      with the nonce value?

Kent

At 06:56 PM 2/7/2005 -0600, Nakhjiri Madjid-MNAKHJI1 wrote:

>Hi folks,
>
>
>
>Just wanted to let you know that we just submitted a draft proposing an 
>specification for support of RADIUS for Mobile IP key management 
>procedures. The draft goes through two cases of co-located mobile nodes 
>and nodes behind an FA and describes RADIUS messaging and attributes for 
>each case. Since the draft deals with both Mobile IPv4 and RADIUS, it 
>needs to be examined by both groups. We know that this is really more an 
>extension to RADIUS than to Mobile IP and should be standardized by RADIUS 
>groups, but we would like to make sure that we got the Mobile IP parts 
>right first J.
>
>
>
>So comments and guidance are very welcome.
>
>
>
>Thanks and Regards,
>
>
>
>Madjid Nakhjiri, Kuntal Chowdhury, Avi Lior
>
>
>
>
>
>The draft can be found at
>
>
>
><http://www.ietf.org/internet-drafts/draft-nakhjiri-radius-mip4-00.txt>http://www.ietf.org/internet-drafts/draft-nakhjiri-radius-mip4-00.txt
>
>
>
>
>
>Abstract
>
>
>
>    Mobile IPv4 specifies mechanisms that need assistance from a AAA
>
>    server and a AAA infrastructure. Examples of such mechanisms are
>
>    those providing key management and authentication services during a
>
>    mobile node's registration process with MN-AAA authentication
>
>    extension. Although Diameter Mobile IP application is being specified
>
>    to support the needs of Mobile IPv4 from the AAA infrastructure's
>
>    point of view, such support does not exist within RADIUS framework.
>
>    This document defines the RADIUS attributes that provide support for
>
>    Mobile IPv4 operation.
>
>
>
>
>--
>Mip4 mailing list: [e-mail]
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html
>Supplemental site: http://www.mip4.org/

--
      |           |                   Kent Leung
     :|:         :|:                  IP Mobility Development
    :|||:       :|||:                 Internet Technologies Division
   :|||||||:   :|||||||:              Voice: 408.526.5030
.:|||||||||:.:|||||||||:.             Fax:   [phone]
  c i s c o S y s t e m s             Email: [e-mail] 

-- 
Mip4 mailing list: [e-mail]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/