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

[Madjid Nakhjiri <mnakhjiri at huawei.com>]

Actually there is the draft-nakhjiri-radius-mip4-02.txt that was submitted
to mip4 WG for specifying how this can be supported through RADIUS. That
draft is now expired. We have not submitted a new version, since the IESG
asked us to submit a requirement document first stating that we will not try
to improve RADIUS functionality for support of MIP4. The work is pending
working group review of the requirement work
draft-ietf-mip4-radius-requirements-00.txt by the wG and later IESG. The
requirement doc has also expired, and we need to resubmit it, with a new
date basically:) If you are interested and cannot find these drafts over the
web, let me and know and I send it to you.
My plan is to submit the requirement-01 as soon as I get to it. But that
should not stop people from reviewing it, all that is going to change is the
doc date.

Thanks and Regards,

Madjid

-----Original Message-----
From: McCann Peter-A001034 [mailto:pete.mccann at motorola.com] 
Sent: Wednesday, November 08, 2006 8:58 AM
To: Arun SG; mip4 at ietf.org
Subject: RE: [Mip4] Query regarding MN-AAA authenticator calculation.

RFC 4004 describes a Diameter application that can be used
by the FA to verify the challenge-response and propagate
the Registration Request to a home agent in another domain.

There is not currently an IETF specification for what happens
in RADIUS but we may be taking up that work in future.

-Pete

Arun SG wrote:
> Thanks, Peter.
> This is certainly helpful. Is there work underway that would cover
> the FA action in case of MN-AAA authentication ? 
> Arun
> 
> -----Original Message-----
> From: McCann Peter-A001034 [mailto:pete.mccann at motorola.com]
> Sent: Tuesday, November 07, 2006 11:12 PM
> To: Arun SG; mip4 at ietf.org
> Subject: RE: [Mip4] Query regarding MN-AAA authenticator calculation.
> 
> 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:
>> <EBF631554F9CD7118D0B00065BF34DCB18379493 at il27exm03.cig.mot .com>
>> List-help: <mailto:mip4-request at ietf.org?subject=help>
>> List-id: Mobility for IPv4 <mip4.ietf.org>
>> List-post: <mailto:mip4 at ietf.org>
>> List-subscribe: <https://www1.ietf.org/mailman/listinfo/mip4>,
>> <mailto:mip4-request at ietf.org?subject=subscribe>
>> List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip4>,
>> <mailto:mip4-request at ietf.org?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:   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/
>> 
>> 
>> 
>> 
>> 
>> 
>
------------------------------------------------------------------------
>> --------
>> 
>> 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: 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/