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

["Jayshree Bharatia" <[e-mail]>]

Hi Kent,

Regarding point 1 of your comments, this RADIUS draft can refer to the
latest version of RFC3012bis document (draft-ietf-mip4-rfc3012bis-03.txt). 

Regards,
Jayshree
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Kent
Leung
Sent: Wednesday, March 23, 2005 7:06 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Nakhjiri Madjid-MNAKHJI1; '[e-mail]';
'[e-mail]'; '[e-mail]'
Subject: Re: [Mip4] draft on RADIUS support for Mobile IP


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

 

    

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/