RE: [Mip4] Query regarding MN-AAA authenticator calculation.

[Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri at motorola.com>]

Hi Kent, 

thanks for the email. The doc clearly says the method by which the MN gets a challenge is out of scope. If the MN is collocated (there is no FA), what is the meaning of Mobile-foreign challenge extension? 
We thought you would not need any challenge if the MN is collocated and registers with HA directly, did we miss anything?

Madjid

-----Original Message-----
From: Kent Leung [mailto:kleung at cisco.com] 
Sent: Friday, March 04, 2005 7:21 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'Pete McCann'; Archana; mip4 at ietf.org
Subject: RE: [Mip4] Query regarding MN-AAA authenticator calculation.

Hi Madjid.  The rfc3012bis draft covers the CCoA mode.

>Based on local policy, a Mobile Node with co-located care-of-address
>    MAY include the Mobile-AAA Authentication extension in Registration
>    Request.  In this case, if the Mobile Node uses SPI value of CHAP_SPI
>    or HMAC_CHAP_SPI (section 8) in the MN-AAA Authentication extension,
>    Mobile Node MUST include the Mobile-Foreign Challenge extension prior
>    to the Mobile-AAA Authentication extension.  The mechanism used by
>    the Mobile Node to obtain the Challenge value is outside the scope of
>    this document.

Kent


At 03:52 PM 3/4/2005 -0600, Nakhjiri Madjid-MNAKHJI1 wrote:
>Hi,
>
>I have been meaning to respond to this as well. I agree there is no RADIUS 
>MD5. However, there is a problem with sending all the following
>
>Preceding Mobile IP data ||
>         Type, Subtype (if present), Length, SPI) ||
>        Least-order 237 bytes from Challenge
>
>Over RADIUS messages, since RADIUS packets can be at most 4K long and 
>attributes at most 253 bytes (if I understood this correctly), which means 
>you do have to calculate a hash of the data above before packing it over 
>RADIUS messaging, if you want the AAA server to do the same calculations. 
>If anybody has a number on the number of bytes the data above takes, I 
>would appreciate it??
>We tried to explain this in our draft on RADIUS support for MIP-AAA signaling.
>
>http://www.ietf.org/internet-drafts/draft-nakhjiri-radius-mip4-00.txt
>
>We ran into another problem with this and that was: the challenge is used 
>only in conjunctions with FAs and when the MN uses a CcoA and registers 
>through HA directly, there won't be any challenge to calculate
>
>MD5      (High-order byte from Challenge || Key ||
>         MD5(Preceding Mobile IP data ||
>         Type, Subtype (if present), Length, SPI) ||
>         Least-order 237 bytes from Challenge))
>
>Our proposal based on Charlie's suggestion (no mean to push the blame, 
>Charlie :) ) was to include zero octets whenever challenge data was needed 
>in that case.
>
>Any thoughts?
>
>Madjid
>-----Original Message-----
>From: mip4-bounces at ietf.org [mailto:mip4-bounces at ietf.org] On Behalf Of 
>Pete McCann
>Sent: Friday, February 25, 2005 9:48 AM
>To: Archana
>Cc: mip4 at ietf.org
>Subject: [Mip4] Query regarding MN-AAA authenticator calculation.
>
>
>Hi, Archana,
>
>Archana writes:
>  > Hi
>  > According to RFC 3012, the MN-AAA authenticator is computed by 
> applying MD5
>  > on the following data
>  >
>  >       High-order byte from Challenge || Key ||
>  >       MD5(Preceding Mobile IP data ||
>  >       Type, Subtype (if present), Length, SPI) ||
>  >       Least-order 237 bytes from Challenge
>  >
>  > I have the following queries regarding the above computation. Any help in
>  > the clarifying them will be highly appreciated.
>  >
>  > 1. What is meant by High-order and Least order ?
>
>"High-order" means "most significant".  You can also interpret it as
>"leftmost" when looking at the encoding of the Challenge in a Mobile
>IP Extension.
>
>  > 2. How does the Radius MD5 algorithm differ in calculating the 
> Authenticator
>  > from a MD5 algorithm
>
>There is no special "Radius MD5" as far as I know.
>
>MD5 is specified in RFC3121.  It is a well-known hash function that
>processes the input and produces a 16 octet hash.
>
>The calculation shown above is compatible with existing RADIUS servers
>that are used for authenticating PPP/CHAP, i.e., the code used for
>PPP/CHAP can be re-used to compute the above authenticator, assuming
>that the FA can precompute the inner MD5 and send it in an
>Access-Request.
>
>-Pete
>
>  > Thanks in advance
>  > Archana
>
>
>--
>Mip4 mailing list: Mip4 at ietf.org
>     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/
>
>--
>Mip4 mailing list: Mip4 at ietf.org
>     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: kleung at cisco.com

-- 
Mip4 mailing list: Mip4 at ietf.org
    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/