Subject: [MOBILE-IP] Mobile IP Challenge/Response Extensions

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 6 Dec 1999 15:15:36 -0800

Hello folks,

I have sent a revised Challenge draft in for publication,
in response to comments received during Last Call.  For those
who do not wish to wait until the draft is available from the
standard directories, it can be retrieved from the following URL:
        http://www.iprg.nokia.com/~charliep/txt/mobilechal/mip-chal.txt

There are two notable changes in the revised draft, besides the
usual collection of wording changes.

1) The MN-AAA authentication extension is redefined to be
   a subtype of a Generalized Authentication extension.

   This follows along the same philosophy as contained within the
   recently proposed MIER draft, and is in the spirit of general
   discussions along these lines that have surfaced from time to time
   over the last several years within the Mobile IP working group.

2) The RADIUS algorithm is specified as a reserved SPI number,
   hopefully SPI == 2.  Right now, the only other reserved SPI
   number is SPI == 1, for SKIP.  I think it falls within the
   intended application of reserved SPI numbers for there to be
   SPIs that designate such specific algorithms as in this case.
   Furthermore, I think that the reserved SPI numbers are even
   more appropriate for AAA servers that do not look at the SPI
   number.

I hope that the newly revised draft and its improved functionality
will meet the expectations and needs of the cellular requirements
drafts and interested parties, as well as providing support for
future similar requirements without cramping the available space
for extension numbers.

Regards,
Charlie P.

---

From: Pete McCann <[email-masked]>
Date: Tue, 7 Dec 1999 14:38:35 -0600

Hi, Charles,

I just read over the new draft.  I have no particular problem with the
fact that the RADIUS algorithm now has a reserved SPI instead of a new
extension, but I think the following text in Section 6.1 describing
the default algorithm now does not make sense:

   Just as with Mobile IP, MD5
   in the prefix+suffix mode MUST be able to be configured for selection
   at any arbitrary 32-bit SPI.

This implies that it may even be configured at SPI=2 (the reserved
value for the RADIUS algorithm).  I hope that this sentence can be
deleted.

Also, does it make sense to move section 5 to be section 6.2?  It
seems like discussion of the reserved SPI should be after presentation
of the authentication extension itself.

-Pete

"Charles E. Perkins" <[email-masked]> (CEP) writes:

CEP> Hello folks,
CEP> I have sent a revised Challenge draft in for publication,
CEP> in response to comments received during Last Call.  For those
CEP> who do not wish to wait until the draft is available from the
CEP> standard directories, it can be retrieved from the following URL:
CEP>         http://www.iprg.nokia.com/~charliep/txt/mobilechal/mip-chal.txt

CEP> There are two notable changes in the revised draft, besides the
CEP> usual collection of wording changes.

CEP> 1) The MN-AAA authentication extension is redefined to be
CEP>    a subtype of a Generalized Authentication extension.

CEP>    This follows along the same philosophy as contained within the
CEP>    recently proposed MIER draft, and is in the spirit of general
CEP>    discussions along these lines that have surfaced from time to time
CEP>    over the last several years within the Mobile IP working group.

CEP> 2) The RADIUS algorithm is specified as a reserved SPI number,
CEP>    hopefully SPI == 2.  Right now, the only other reserved SPI
CEP>    number is SPI == 1, for SKIP.  I think it falls within the
CEP>    intended application of reserved SPI numbers for there to be
CEP>    SPIs that designate such specific algorithms as in this case.
CEP>    Furthermore, I think that the reserved SPI numbers are even
CEP>    more appropriate for AAA servers that do not look at the SPI
CEP>    number.

CEP> I hope that the newly revised draft and its improved functionality
CEP> will meet the expectations and needs of the cellular requirements
CEP> drafts and interested parties, as well as providing support for
CEP> future similar requirements without cramping the available space
CEP> for extension numbers.

CEP> Regards,
CEP> Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 7 Dec 1999 13:04:21 -0800

Hello Pete,

Thanks for your note.

>       ...    I think the following text in Section 6.1 describing

Actually, there are two things wrong with that sentence.  A good
replacement sentence might be:

   Just as with Mobile IP, this default algorithm MUST be able to be
   configured for selection at any arbitrary 32-bit SPI outside of
   the SPIs in the reserved range 0-255.

This formulation is better because Mobile IP makes a specificaition
about the _default algorithm_.  The default algorithm requires more
than just using MD5 in prefix+suffix mode.

> of the authentication extension itself.

I'd rather move it to be section 7 instead of section 6.2, since the
idea of SPI == 2 is substantially independent from the idea of
the Generalized Authentication extension.  Would that make better
sense to you?

Regards,
Charlie P.

---

From: Pete McCann <[email-masked]>
Date: Tue, 7 Dec 1999 15:26:49 -0600

Hi, Charles,

CEP> Actually, there are two things wrong with that sentence.  A good
CEP> replacement sentence might be:

CEP>    Just as with Mobile IP, this default algorithm MUST be able to be
CEP>    configured for selection at any arbitrary 32-bit SPI outside of
CEP>    the SPIs in the reserved range 0-255.

CEP> This formulation is better because Mobile IP makes a specificaition
CEP> about the _default algorithm_.  The default algorithm requires more
CEP> than just using MD5 in prefix+suffix mode.

Makes sense.  As long as the SPI=2 value is universally understood (even
by visited FAs) to refer to the RADIUS algorithm, I am happy.

>> of the authentication extension itself.

CEP> I'd rather move it to be section 7 instead of section 6.2, since the
CEP> idea of SPI == 2 is substantially independent from the idea of
CEP> the Generalized Authentication extension.  Would that make better
CEP> sense to you?

That would be ok, although putting it on the same logical footing as
the default algorithm makes a little more sense to me.  But I am happy
either way as long as the algorithm itself is given somewhere in the
document.

CEP> Regards,
CEP> Charlie P.

-Pete