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

["McCann Peter-A001034" <[e-mail]>]

Hi, Arun,

Arun SG wrote:
> Hello,
> Please refer to the old thread pasted below. Can someone please
> provide a few followup clarifications ? 
> 
> 1. What is the current status of 3012bis?

3012bis is currently in AUTH48, one of the very last stages before
publication.  I think we are still waiting on responses from a couple
of the authors.

> 2. This para in 3012 and 3012bis states:
> 
> If the MN-AAA Authentication extension (see Section 6) is present in
> the message, or if an NAI extension is included indicating that the
> mobile node belongs to a different administrative domain, the foreign
> agent may take actions outside the scope of this protocol
> specification to carry out the authentication of the mobile node.    
> 
> Does this then mean that this specification is restricted to the case
> when the MN, FA and AAA all belong to the same administrative domain? 

Certainly not.  It just says that the action taken by the FA to
validate the MN-AAA extension is outside the scope of this document.

> 3. While CHAP_SPI declares that MD5 is to be used, I could not find a
> description of how the "key" that is to be used in MD5 is obtained.
> Is there an implicitly understanding that this is preshared, or
> perhaps obtained through some other key exchange mechanims ?   

The "key" is a long-term secret shared between the MN and the
home AAA server.  It is configured using out-of-band mechanisms that
are outside the scope of 3012.
> 
> MD5      (High-order byte from Challenge || Key || <<<<------is this
> thru' IKE or some other means?
>         MD5(Preceding Mobile IP data ||
>         Type, Subtype (if present), Length, SPI) ||
>         Least-order 237 bytes from Challenge))
> 
> Thanks in advance,
> Arun

Hope this helps.

-Pete

> 
> 
> RE: [Mip4] Query regarding MN-AAA authenticator calculation.
> 
>
------------------------------------------------------------------------
> --------
> 
> To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri at motorola.com>
> Subject: RE: [Mip4] Query regarding MN-AAA authenticator calculation.
> From: Kent Leung <kleung at cisco.com>
> Date: Fri, 04 Mar 2005 17:21:21 -0800
> Cc: "'Pete McCann'" <mccap at lucent.com>, Archana <archana_p at
> huawei.com>, mip4 at ietf.org
> In-reply-to:
> <[e-mail] .com>
> List-help: <mailto:[e-mail]?subject=help>
> List-id: Mobility for IPv4 <mip4.ietf.org>
> List-post: <mailto:[e-mail]>
> List-subscribe: <https://www1.ietf.org/mailman/listinfo/mip4>,
> <mailto:[e-mail]?subject=subscribe>
> List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip4>,
> <mailto:[e-mail]?subject=unsubscribe>
> Sender: mip4-bounces at ietf.org
> 
>
------------------------------------------------------------------------
> --------
> 
> 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:   [phone]
>  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/
> 
> 
> 
> 
> 
>
------------------------------------------------------------------------
> --------
> 
> Prev by Date: RE: [Mip4] Query regarding MN-AAA authenticator
> calculation.
> Next by Date: [Mip4] [Deadline Approaching] Final CFP: IEEE
> WirelessCom 
> Symposium on Mobile Computing, 2005
> Previous by thread: RE: [Mip4] Query regarding MN-AAA authenticator
> calculation.
> Next by thread: RE: [Mip4] Query regarding MN-AAA authenticator
> calculation.
> Index(es):
> Date
> Thread
> Note: Messages sent to this list are the opinions of the senders and
> do 
> not imply endorsement by the IETF.


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