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

From: Kent Leung <[email-masked]>
Date: Wed, 23 Mar 2005 17:06:00 -0800

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: [email-masked]
>     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:   408.525.1653
  c i s c o S y s t e m s             Email: [email-masked] 

-- 
Mip4 mailing list: [email-masked]
    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/

---

From: "Jayshree Bharatia" <[email-masked]>
Date: Thu, 24 Mar 2005 13:07:13 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Kent
Leung
Sent: Wednesday, March 23, 2005 7:06 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]';
[email-masked]'; [email-masked]'
Subject: Re: [Mip4] draft on RADIUS support for Mobile IP

Hi Madjid et al.,

    

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.

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.

     responsible to authenticate the MN and provide the keys to the HA,
which

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.

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?

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

Kent

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.

Thanks and Regards,

 

http://www.ietf.org/internet-drafts/draft-nakhjiri-radius-mip4-00.txt

Abstract 

   Mobile IPv4 operation.

---

From: Kent Leung <[email-masked]>
Date: Fri, 25 Mar 2005 16:30:11 -0800

Hi Madjid.  Comments inline.

At 04:56 PM 3/25/2005 -0600, Nakhjiri Madjid-MNAKHJI1 wrote:

>Hi Kent,
>
>
>
>Really appreciate the thorough read and useful comments. You are hitting 
>on many issues that we wanted this group to look at.
>
>I am making the mods to the draft as I am responding to you, so in this 
>email I will not get to respond to all of your comments. I will send 
>another email later on to the comments I am not responding to now.
>
>
>
>I can send you the modified draft over a direct link if you like.
>
>
>
>Regards,
>
>
>
>Madjid
>
>
>
>From: Kent Leung [mailto:[email-masked]]
>Cc: [email-masked]; Nakhjiri Madjid-MNAKHJI1; 
>[email-masked]; [email-masked]
>Madjid>>Thanks
>Madjid>>I have 03 on rfc3012bis, I think you meant 06 of the key draft, 
>which is now RFC. Anyway, both references are updated now.
>
>
>Madjid>> We were trying to cover the case, when the user does not have an 
>HoA and wants to request one from the AAA server or HA. So both NAI and 
>HoA can be used but we do not use both AVPs, only one will be used as the 
>value for User-Name, so prioritization there. I changed to text so it 
>reads properly now.
>
>The values insides parentheses following the attributes represent various 
>alternatives for attribute values. In other words, for User-Name attribute 
>either MIP-MN-HoA or MIP-MN-NAI can be used, depending on whether the MN 
>has included an HoA or an NAI as identifier at the time of registration or 
>includes its NAI to indicate to the HA and AAA server that it requires an 
>HoA assignment. However, only one alternative will be included in the 
>User-Name attribute. Attributes included inside "<>" are optional. The HA 
>includes its own IP address as the value for NAS IP attribute.

Ah, originally I interpreted attributes inside parentheses as optional AVPs 
to the
message.  Now it's clearer these are the optional values.  But raises the
next issue for "NAS-IP (MIP-HA-IP address or MIP-HA-NAI)".  The NAS-IP
AVP may not be able to fit MIP-HA-NAI value.

>I am not quite sure whether we need the MIP-MN-NAI and MIP-MN-HoA as new 
>attributes or just as values for the existing User-name attribute. 
>Something to find out from RADEXT.

I'm fine with User-Name AVP with values from MIP-MN-NAI or MIP-MN-HoA.
The NAS-IP AVP threw me off since it had NAI which usually don't fit in
4 byte field.  So I assume that the parentheses meant additional AVPs.

>Madjid>> Well, this is an area where 3012bis has problem. The challenge 
>that the MN uses in MFCE can only come from the challenge extension inside 
>agent advertisement from FAs (section 2). 3012bis does not define where 
>the challenge come from if there is no FA (CcoA mode). So we had to 
>replace the challenge with zero to be able to complete the MD5 hashing of 
>RRQ for RADIUS as described in 3012bis.
>

3012bis said outside of scope.  The challenge value may be 0 or non-zero.
But the MFCE is required.  One method is the MN generates the challenge
value.

>Madjid>>If the HA is the NAS, then the HA IP can be included in NAS IP, 
>but if FA is the NAS, then HA IP needs to go separartely. One thing we 
>were trying to support was a case when the MN does not know the IP address 
>of the HA and puts zeros in the RRQ fields to request for HA allocation. 
>So I added the following text to that section.
>
>

Even if the HA is the NAS, the HA IP address and NAS IP address may be 
different.
Maybe this needs to be mentioned?  Only in the case that HA IP address is 
the same
as NAS IP address, then MIP-HA-IP is not needed.

>If the HA does not find its own IP address inside the RRQ from the MN, the 
>HA needs to set the value of "Home-Agent-Requested" inside 
>MIP-feature-vector to indicate to the AAA server that MN has requested an 
>HA assignment.
>This is definitely a case where the HA can put its own IP address in NAS IP.
>
>
>
>Madjid>>Done.
>Madjid>>Thanks, done.
>Madjid>>added the reference.
>Madjid>> I guess my laziness caught up with meJ Done.
>
>
>Madjid>>  ")" fixed. FA-IP is now inside NAS-IP. If MN does not have an 
>HA, we need to do something, not sure if MIP-FA-NAI is good either.
>
>

I think the FA-IP may be different than NAS-IP.  It doesn't hurt to have 
MIP-FA-NAI,
which can identify the FA which may be useful for dynamic HA assignment
in foreign network.

>      to set up the FA-HA MSA.  Also, the MIP-MN-FA-nonce is missing in 
> the list for
>      Access-Request.
>Madjid>> Not sure what purpose nonce would serve here, based on your other 
>comments below I think the FA-HA-SPI serves the same purpose. See my 
>comments below and let me know if you agree.

The key is to identify the FA-HA MSA on the RADIUS server.  I think
FA id, HA id, and FA-HA-SPI is sufficient.

>Added the MN-FA nonce, thanks,
>
>
>
>
>Madjid>>thanks again.
>Madjid>> fixed NAS-IP (I think). Because, by now only FA got its keys. HA 
>does not have them yet.
>
>I thought the FA-to-HA-SPI will serve as an index for the AAA to find the 
>key that it has generated for FA-HA. So whether it uses SPI or FA-NAI for 
>lookup is something we need to agree on. And this is why I think a new 
>FA-HA-nonce not needed.

Agree with using FA id, HA id, and SPI to index the MSA.  But
why is the MIP-FA-HA-Authenticator in the msg?

>It will confuse the reader, since in the [MIPKEYS] the MN uses the nonce 
>to generate keys.
>
>I added your last comment on FHAE, good point.
>
>
>Madjid>> well, the framework is trying to accommodate FA-HA MSA 
>establishment, so that "finds the MSA" thing is just so that the AAA can 
>locate the keys that it gave to FA and give them to HA. Did we give the 
>impression that the AAA server also verifies the FHAE?

Yes.  When I saw the MIP-FA-HA-Authenticator, I assume that was used for
authentication.  If only to look up MSA, the triplet will suffice.

>       AVPs?  These were already delivered to the FA in the RADIUS 
> exchange between
>       FA and AAAF.
>
>Because, my impression was that the HA builds both the MN-HA-nonce reply 
>and MN-FA-nonce reply when it is building the RRP and before signing the 
>MN-HA-AE. In that case the HA would need  that info, even though it was 
>delivered to FA before.

I got that same impression.  But this doesn't see right to me since the
key nonce are protected by MHAE from HA, and MFAE from FA.  So
not sure why HA needs to handle MN-FA nonce.  Have to check the
draft to confirm.

>15) "The HA retreives the key materials" bullet, I don't think HA should 
>be putting
>Madjid>> same as above.
>Madjid>> same as above.

What does keygen draft say?

>
>
>OK, I think I need to start leaving for the weakend now, I will respond to 
>your other comments later as I will fix the rest of the draft.

OK.

Kent

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 29 Mar 2005 17:01:34 -0600

Hi Kent, 

Sending comments to the rest of your questions. 

-----Original Message-----
From: Kent Leung [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2005 7:06 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]; Nakhjiri Madjid-MNAKHJI1; [email-masked]; [email-masked]
Subject: Re: [Mip4] draft on RADIUS support for Mobile IP

<snip>

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.

Madjid>>That would make sense to Mobile IP folks, but I am not if RADIUS folks would be happy if their message needs to carry two attributes with different names carrying the same info. Here is a question: Diameter has the notion of "applications", Mobile IP is an application for Diameter. If the server knows you are running the Mobile IP application, then depending on the message, it knows it is coming from a client that is also a mobile IP agent. In RADIUS you cannot define new messages, so we need to ask the question of whether the RADIUS server needs to know if a NAS is an FA or an HA. If we decide that distinguishing of FA and HA is important for the operations here (I think it is, then we need to change this statement. I put a comment in that effect there.

(By receiving the Mobile IP related RADIUS attributes, the server will know that it is receiving Access Requests from a NAS that is also a Mobile IP agent. If it is shown that the RADIUS server need to be able to distinguish an FA and an HA, then the MIP-HA-IP-address or MIP-FA-IP-address attributes need to also be included)

what do you think?

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.

Madjid>> based on what we just said, I cannot remember why we added that statement. I will mark it for now and if it is needed, I remove the text.

19) MIP-MN-AAA-SPI, String should be unsigned32 and Length should be 6.
Madjid>>thanks, good point. Changed all the SPIs accordingly.

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.  

Madjid>>checked the Diameter MIP, true. Changed accordingly. Thanks. 

Why not unsigned8, by the way?

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?

Madjid>>We are not against any of that, we were just keeping things simple until we make sure  our suggested operation suggested that. Come to think about it, no harm in defining the attributes before hand. Done.

22) MIP-MN-to-HA SPI and MIP-HA-to-MN-SPI , String should be unsigned32 and length is 6.
Madjid>>done.
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?

Madjid>>The strings are the products of cut and paste before the deadline phenomenon :-)

Will change to unsigned8. do you want a table with identifier values? Isn't SHA1 becoming popular now?

Should I have separate values for HMAC-MD5 and MD5? Do people do MD5 alone?

Madjid>>done.

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

Madjid>>done. Not sure about the infinite lifetime. I am wondering in general who determines and enforces these lifetimes? How do you know whether an MSA belongs to this session or the previous one? And why would the MSA be valid only for one registration?

Madjid>> not sure if I follow??

Madjid>>done.

28) Would like to add new MIP-FA-HA-nonce AVP.
Madjid>>see my previous comments on FA-HA nonce versus FA-HA SPI.

29) In 5.1, attribute list is missing MIP-FA-NAI,

Madjid>> added

MIP-MN-HA SPI and MIP-HA-to-MN-SPI should change "HA" to "FA" 

Madjid>>good catch on my cut and pastes. Thanks.

before "Encrypted", missing Encrypted[MIP-MN-FA-key],

Madjid>>done.

Madjid>>previous comment. Fixed duplicate.

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?
Madjid>> only from HA to MN, not over RADIUS from AAAH to MIP agents, at least, I think this is what I meant.

Kent

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

Thanks and Regards,

 

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

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

--

     |           |                   Kent Leung

---

From: Kent Leung <[email-masked]>
Date: Tue, 29 Mar 2005 15:54:52 -0800

Hi Madjid.  Comments below.

At 05:01 PM 3/29/2005 -0600, Nakhjiri Madjid-MNAKHJI1 wrote:

>Madjid>>That would make sense to Mobile IP folks, but I am not if RADIUS 
>folks would be happy if their message needs to carry two attributes with 
>different names carrying the same info. Here is a question: Diameter has 
>the notion of "applications", Mobile IP is an application for Diameter. If 
>the server knows you are running the Mobile IP application, then depending 
>on the message, it knows it is coming from a client that is also a mobile 
>IP agent. In RADIUS you cannot define new messages, so we need to ask the 
>question of whether the RADIUS server needs to know if a NAS is an FA or 
>an HA. If we decide that distinguishing of FA and HA is important for the 
>operations here (I think it is, then we need to change this statement. I 
>put a comment in that effect there.
>
>(By receiving the Mobile IP related RADIUS attributes, the server will 
>know that it is receiving Access Requests from a NAS that is also a Mobile 
>IP agent. If it is shown that the RADIUS server need to be able to 
>distinguish an FA and an HA, then the MIP-HA-IP-address or 
>MIP-FA-IP-address attributes need to also be included)
>
>what do you think?

The HA or FA identifiers include MIP-HA-NAI and MIP-FA-NAI, right?  These 
would not fit
into the NAS-IP AVP.  I think this text is fine as long as NAI is in there too.

>Madjid>> based on what we just said, I cannot remember why we added that 
>statement. I will mark it for now and if it is needed, I remove the text.
>
>
>
>
>

There's already over 8 bits assigned.  And when someone creates RADIUS/DIAMETER
gateway, it's better to have same size fields. :)

>Madjid>>We are not against any of that, we were just keeping things simple 
>until we make sure  our suggested operation suggested that. Come to think 
>about it, no harm in defining the attributes before hand. Done.
>
>
>Madjid>>The strings are the products of cut and paste before the deadline 
>phenomenon J
>

Yes, keyed MD5 was in RFC 2002 and HMAC-MD5 was in RFC 3344.  SHA1 is
not defined in any MIPv4 RFC.

>Madjid>>done. Not sure about the infinite lifetime. I am wondering in 
>general who determines and enforces these lifetimes? How do you know 
>whether an MSA belongs to this session or the previous one? And why would 
>the MSA be valid only for one registration?
>

Generally, the MSA between MN and HA has infinite lifetime, as there are
not standards mechanism to rekey.  So there is no need for enforcement
for lifetime.

A session exists when there is a mobility binding, which is renewed by
re-registrations.  So once the mobility binding goes away, the session
is over.  The reason why MSA is valid for one session is to enforce
AAA authorization when a new session is started.  This means starting
a new session requires AAA authentication/authorization again.

I was thinking about having another option for AAA to tell HA to keep it
forever.  But not sure why the MSA should remain between sessions.
Maybe we could use lifetime = 0 to serve this purpose?

>Madjid>> not sure if I follow??

hmm, can't remember why either.

>least, I think this is what I meant.

Oh well, I'm still not clear.  The Message-Authenticator AVP should
protect the nonce value between AAAH and MIP agents.  The MHAE
or MFAE should protect the nonce value between MN and HA or
MN and FA, respectively.  So what does AAAH also authenticates
the nonce reply with SA with MN?  The nonce will be use to derive
MHAE/MFAE key for authenticating RRP, which means that nonce
could not have been tempered with.  I'm missing something probably?

Thanks.

Kent

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 31 Mar 2005 17:52:50 -0600

Hi Kent,

I think the issue with NAI not fitting into the NAS_IP can be solved by simply adding optional 

MIP-FA-NAI and MIP-HA-NAI whenever needed. So the NAS_IP only carries the IP address of the MIP agent that carries the RADIUS Access Request. I think we should keep the optional NAIs there if RADIUS requires them.

Here is the suggested text that was added:

If the HA IP address is available from RRQ, the FA includes it inside MIP-HA-IP-address attribute. Otherwise the FA inserts the HA NAI from the RRQ inside the MIP-HA_ID attribute. Note that at least one of MIP-HA-IP-address and MIP-HA-NAI must be present for identification of the HA at the AAA server. If the NAIs are required for RADIUS routing, the FA include its own NAI inside the MIP-FA-ID and HA NAI inside MIP-HA-NAI. The following attributes are included in this request:

RADIUS-Access Request {

User-Name (MIP-MN-HoA or MIP-MN-NAI)

NAS-IP (MIP-FA-IP-address)

<MIP-HA-IP-address>(if available), 

<MIP-HA-NAI> if HA address all 1s or 0s)

<MIP-FA-ID> if the HA address is all 1s or all 0s),

.....

see other inline comments.

Madjid>> Well, this is an area where 3012bis has problem. The challenge that the MN uses in MFCE can only come from the challenge extension inside agent advertisement from FAs (section 2). 3012bis does not define where the challenge come from if there is no FA (CcoA mode). So we had to replace the challenge with zero to be able to complete the MD5 hashing of RRQ for RADIUS as described in 3012bis.

Madjid>>>>I see, we just taught the implementation would be easier if a CcoA MN inserts zeros. Not sure what a challenge generated by MN achieves? You do have the time stamp to protect the HA from replays.

Even if the HA is the NAS, the HA IP address and NAS IP address may be different.
Maybe this needs to be mentioned?  Only in the case that HA IP address is the same
as NAS IP address, then MIP-HA-IP is not needed.

Madjid>>>> added preliminary text for this, but why would HA IP<>NAS IP?

I think the FA-IP may be different than NAS-IP.  It doesn't hurt to have MIP-FA-NAI,
which can identify the FA which may be useful for dynamic HA assignment
in foreign network.

Madjid>>>> added, but same question as before?

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.

Madjid>> fixed NAS-IP (I think). Because, by now only FA got its keys. HA does not have them yet.

I thought the FA-to-HA-SPI will serve as an index for the AAA to find the key that it has generated for FA-HA. So whether it uses SPI or FA-NAI for lookup is something we need to agree on. And this is why I think a new FA-HA-nonce not needed. 

Madjid>>>> You are right, I deleted it.

     MIP-MN-AAA-Authenticator.  Also, if the AAA server receives the MIP-FA-HA-nonce,

Madjid>> well, the framework is trying to accommodate FA-HA MSA establishment, so that "finds the MSA" thing is just so that the AAA can locate the keys that it gave to FA and give them to HA. Did we give the impression that the AAA server also verifies the FHAE? 

Madjid>>>>MFHAuth deleted.

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.

Because, my impression was that the HA builds both the MN-HA-nonce reply and MN-FA-nonce reply when it is building the RRP and before signing the MN-HA-AE. In that case the HA would need  that info, even though it was delivered to FA before.

Madjid>>>>Appreciate it.

Regards,

Madjid