Subject: Re: [MOBILE-IP] Foreign Agent Challenge

From: Patrice Calhoun <[email-masked]>
Date: Tue, 5 Oct 1999 08:46:15 -0700

It is quite clear that there is consensus that the challenge draft needs to
address RADIUS as well as another more feature-rich AAA infrastructure.
Having throught about the problem, and possible solutions, I have come to the
conclusion that I am not fond of a well-known SPI, or ID. What I would prefer
to have are *two* separate authentication extensions in the draft, one being
the MN-AAA, which already exists, and one being the MN-RADIUS extension.

This means that Mobile Nodes that have an SA with a RADIUS server MUST use
the MN-RADIUS extension, while others could use the MN-AAA. This, I believe,
would make it MUCH simpler for foreign agents to identify the challenge-style
rather than having to lookup an ID and/or SPI, both of which would require
IANA allocation.

Having not talked to Charlie about this one (since he is out of the country),
I would like to solicit initial comments on the proposal.

PatC

---

From: Pete McCann <[email-masked]>
Date: Tue, 5 Oct 1999 11:40:25 -0500

Hi, Pat,

Adding a new extension sounds like a good idea, but I am a little bit
worried about future extensions to new authentication algorithms.  Are
we using up extension numbers a bit too quickly?  Anyway, hopefully we
won't have to do that - the MN-AAA extension should be "future proof".

I would prefer to call the extension "MN-CHAP" instead of "MN-RADIUS"
because that is really what we are emulating.  How about adding the
following (I am just guessing about the Type 37 - is this number still
free?):

4.3. MN-CHAP Authentication Extension

   The mobile node MAY include this extension in the Registration
   Request when compatibility with CHAP-style authentication is
   required.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Length    |            SPI ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               ... SPI (cont.)        |       Authenticator
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 3: The MN-AAA Authentication Extension

      Type            37 (not skippable) (see [11])

      Length          4 plus the number of bytes in the Authenticator;
                      MUST be at least 20.

      SPI             Security Parameters Index

      Authenticator   The variable length Authenticator field consists
                      random value of at least 128 bits.

   The algorithm for computation of the authenticator is
   MD5 [12] computed on the following data, in the order shown:

         High-order byte from Challenge || Key
      || MD5(Preceding Mobile IP data || Type, Length, SPI)
      || Least-order 237 bytes from Challenge

   where the Type, Length, and SPI are as shown above.  Note that this
   requires a nested inner MD5 calculation over the Preceding Mobile
   IP Data and Type, Length, SPI in order to provide protection against
   replay attacks.  Least-order 237 bytes from Challenge means the entire
   Challenge value if its length is less than 237.  No padding is added in
   this case.

And deleting the following text from 4.2:

   If the mobile node does not include a Mobile-Foreign
   Authentication extension, then it MUST include the MN-AAA
   Authentication extension.

And adding the following text to the intro to section 4:

4. Mobile IP Registration Extensions

   This section specifies new Mobile IP Registration Extensions that are
   used to satisfy a Challenge in an Agent Advertisement.  If the mobile
   node does not include a Mobile-Foreign Authentication extension, then
   it MUST include either the MN-AAA Authentication extension or the
   MN-CHAP Authentication extension.

-Pete

Patrice Calhoun <[email-masked]> (PC) writes:

PC> It is quite clear that there is consensus that the challenge draft
PC> needs to address RADIUS as well as another more feature-rich AAA
PC> infrastructure.  Having throught about the problem, and possible
PC> solutions, I have come to the conclusion that I am not fond of a
PC> well-known SPI, or ID. What I would prefer to have are *two*
PC> separate authentication extensions in the draft, one being the
PC> MN-AAA, which already exists, and one being the MN-RADIUS
PC> extension.

PC> This means that Mobile Nodes that have an SA with a RADIUS server
PC> MUST use the MN-RADIUS extension, while others could use the
PC> MN-AAA. This, I believe, would make it MUCH simpler for foreign
PC> agents to identify the challenge-style rather than having to
PC> lookup an ID and/or SPI, both of which would require IANA
PC> allocation.

PC> Having not talked to Charlie about this one (since he is out of
PC> the country), I would like to solicit initial comments on the
PC> proposal.

PC> PatC

---

From: Jari T Malinen <[email-masked]>
Date: Tue, 5 Oct 1999 20:46:20 +0200

> we using up extension numbers a bit too quickly?

If the use of the extension number space really becomes a problem, why
not apply subtyping to a set of extensions that belong together. This
could be applied in a draft or a related set of drafts so that only
one number describing a class of extensions is consumed.  Even the
vendor extension could be used this way for private sets of extensions
without consuming the number space.

Regards,

Jari Malinen
Researcher, HUT/CS Lab.