RE: [Mip4] Query regarding MN-AAA authenticator calculation.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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/
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.