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

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
>
>
>
>-----Original Message-----
>From: Kent Leung [mailto:kleung@cisco.com]
>Sent: Wednesday, March 23, 2005 7:06 PM
>To: Nakhjiri Madjid-MNAKHJI1
>Cc: mip4@ietf.org; Nakhjiri Madjid-MNAKHJI1; 
>kchowdhury@starentnetworks.com; avi@bridgewatersystems.com
>Subject: Re: [Mip4] draft on RADIUS support for Mobile IP
>
>
>
>Hi Madjid et al.,
>
>The draft looks pretty good overall.  Some comments.
>
>Madjid>>Thanks
>
>
>1) Please reference draft-ietf-mobileip-rfc3012bis-06.txt in document.
>
>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.
>
>
>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?
>
>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.

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

>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).
>
>
>
>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.
>
>
>
>5) General comments for clarity on labels.  XXX-REP to XXX-REPLAY,
>     XXX-LIFE to XXX-LIFETIME, XXX-ALGID to XXX-ALGORID.
>
>
>Madjid>>Done.
>
>
>6) Typo in "The HA receives the RADIUS Access Accept" bullet.  Remove
>     "using and MN to HA MSAs".
>Madjid>>Thanks, done.
>7) Same 3.1 section, "The MN extracts" bullet, specify how the MN-HA key
>     is derived (or reference [MIPKEYS]).
>Madjid>>added the reference.
>8) Figure 2a, label 1, 2, 3, etc. on the flow would be useful.
>Madjid>> I guess my laziness caught up with meJ Done.
>
>
>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.
>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.

>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.
>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,
>
>
>
>
>11) "The FA retrieves the MN-FA key" bullet, typo "Access-Request" should be
>       "Access-Accept".
>
>Madjid>>thanks again.
>
>
>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.

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

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

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
>       MN-FA-nonce.  HA should only put the MN-HA-nonce in the KeyGenReplyExt
>       protected by MHAE.
>Madjid>> same as above.
>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.
>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

--
      |           |                   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: kleung@cisco.com 