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