Subject: Re: [MOBILE-IP] Latest Challenge draft issued

From: Patrice Calhoun <[email-masked]>
Date: Thu, 21 Oct 1999 16:47:29 -0700

>Hello Charlie and Pat:
>
>I have some questions based on 04.txt (see below). Would appreciate if
>you could address them.

Gopal,

Thanks for the comments. most of my comments can be found below with one
exception. There really hasn't been any talk of backward compatibility in
this draft, and I do not think that Charlie and I wanted to open up that
door. Some of the rules in the draft state that the mobile MUST include
the challenge and the response, but an old mobile would not recognize those
and, of course, it wouldn't add them to the registration request. If a foreign
agent is configured to allow access even without the challenge, then I believe
it is a local policy issue, and not one that we need to address in this
draft. First off, how would a foreign agent know that it is dealing with an
old mobile as opposed to a new mobile that is trying to get around the
new authentication scheme?

>
>Thanks
>Gopal
>
>
>
>3.1. Mobile Node Processing for Registration Requests
>
>   Whenever the Agent Advertisement contains the Challenge extension,
>   if the mobile node does not have a security association with the
>   Foreign Agent, then it MUST include the Challenge value in a MN-FA
>
>#GopalQ
>
>Can we a  MUST here. What  happens to  a mobile that  does not
>implement the Challenge/Response???
see above.

>
>
>   Challenge extension to the Registration Request message.  If, on the
>   other hand, the mobile node does have a security association with the
>   foreign agent, it MAY include the Challenge value in its Registration
>   Request message.
>
>
>
>   If the Mobile Node does not have a security association with the
>   Foreign Agent, the Mobile Node MUST include the MN-AAA Authentication
>   extension as defined in section 4.2, or the MN-RADIUS extension as
>
>#GopalQ
>
>How can we mandate a MUST here? What if the Mobile does not implement Challenge
>Repsonse (old mobile) or does not have the appropriate key?
ditto.

>
>
>   defined in section 4.3.  In addition, the Mobile Node SHOULD include
>   the NAI extension [3], to enable the foreign agent to make use of
>   any available verification infrastructure.  The SPI field of the
>   MN-AAA Authentication extension specifies the particular secret
>   and algorithm (shared between the Mobile Node and the verification
>   infrastructure) that must be used to perform the authentication.  The
>   MN-RADIUS extension only supports CHAP-style authentication [13]
>   using MD5 [12], and the SPI field MAY be set to any value.
>
>   In either case, the MN-FA Challenge extension and one of the above
>   specified authentication extensions MUST follow the Mobile-Home
>   Authentication extension, if present.
>
>3.2. Foreign Agent Processing for Registration Requests
>
>   Upon receipt of the Registration Request, if the Foreign Agent has
>   issued a Challenge as part of its Agent Advertisements, and it does
>   not have a security association with the mobile node, then the
>   Foreign Agent MUST check that the MN-FA Challenge extension exists,
>   and that it contains a challenge value previously unused by the
>   Mobile Node.  This ensures that the mobile node is not attempting
>
>Perkins, Calhoun             Expires 25 April 2000              [Page 2]
>
>Internet Draft       Mobile IP Challenge/Response        25 October 1999
>
>   to replay a previous advertisement and authentication.  If the
>   challenge extension is needed and does not exist, the Foreign Agent
>   MUST send a Regstration Reply to the mobile node with the error code
>   MISSING_CHALLENGE.
>
>   If a mobile node retransmits a Registration Request with the same
>   Identification field and the same Challenge extension, and the
>   Foreign Agent still has a pending Registration Request record
>   in effect for the mobile node, then the Foreign Agent forwards
>   the Registration Request to the Home Agent again.  In all other
>   circumstances, if the Foreign Agent receives a Registration
>   Request with a Challenge extension containing a Challenge value
>   previously used by that mobile node, the Foreign Agent SHOULD send
>   a Registration Reply to the mobile node containing the Code value
>   STALE_CHALLENGE.
>
>   The Foreign Agent MUST NOT accept any Challenge in the Registration
>   Request unless it was advertised as one of the last CHALLENGE_WINDOW
>   (see section 5) Challenge values inserted into the immediately
>   preceding Agent advertisements.  If the Challenge is not one of
>   the recently advertised values, the foreign Agent SHOULD send a
>   Registration Reply with Code UNKNOWN_CHALLENGE (see section 6).
>
>   Furthermore, the Foreign Agent MUST check that there is either a
>   Mobile-Foreign, a MN-AAA Authentication, or a MN-RADIUS extension
>   after the Challenge value.  Any registration message containing the
>
>#GopalQ: the same issue of  old mobiles.
ditto.

>
>
>   Challenge value without either of these authentication extensions
>   MUST be silently discarded.  If the registration message contains
>   a Mobile-Foreign Authentication extension with an incorrect
>   authenticator that fails verification, the Foreign Agent MAY
>   send a Registration Reply to the mobile node with Code value
>   BAD_AUTHENTICATION (see Section 6).
>
>   If the MN-AAA Authentication extension (see Section 4.2) 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.
>   For instance, the foreign agent MAY forward the Registration Request
>   to the verification infrastructure (see figure 5 in the Appendix).
>   If the MN-RADIUS extension (see Section 4.3) is present, the foreign
>   agent SHOULD forward the request to the Home Agent, and does not need
>
>
>#GopalQ
>
>Why should this be sent to the Home Agent and not to the verification
>infrastructure.

Because the ROAMOPS WG has deemed RADIUS inappropriate for roaming enviromnents.
Why should we, the Mobile IP WG, state that it is ok to make use of RADIUS?
Note that I was talked down to a SHOULD from a MUST, so if you want to run
RADIUS in a roaming environment, then the draft DOES allow it.
>
>
>4.2. MN-AAA Authentication Extension
>
>   The mobile node MAY include this extension in the Registration
>   Request.  If the mobile node does not include a Mobile-Foreign
>   Authentication extension, then it MUST include the MN-AAA
>   Authentication extension [11] or the MN-RADIUS extension
>
>#GopalQ
>Same issue of old Mobile IP node.
same response about old mobile node.

>
>4.3. MN-RADIUS Extension
>
>   The mobile node MAY include this extension in the Registration
>   Request if it has a security association with a RADIUS server.  If
>   the mobile node does not include a Mobile-Foreign Authentication
>   extension, then it MUST include either the MN-AAA or the MN-RADIUS
>   authentication extension.
>
>       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 4: The MN-RADIUS Extension
>
>Perkins, Calhoun             Expires 25 April 2000              [Page 6]
>
>Internet Draft       Mobile IP Challenge/Response        25 October 1999
>
>      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 default algorithm for computation of the authenticator is
>   MD5 [12] computed on the following data, in the order shown:
>
>      Key || 240 bytes (or less) of preceding Mobile IP data ||
>      Type, Length, SPI
>
>#GopalQ
>
>       I need to verify if this is. will get get back to you.

This *was* changed in the latest version (-05) to:

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

---

From: Gopal Dommety <[email-masked]>
Date: Thu, 21 Oct 1999 17:53:43 -0700

Pat,

Thanks for your reply. My comments below (RADIUS discussion at the end).

> this draft, and I do not think that Charlie and I wanted to open up

I am not sure what you mean by " hasn't been any talk of backward
comaptility in this draft". Are you saying that all the mobiles have
to support Challenge-Responce? and the FAs that supports those old
mobiles as well as the new ones cannot be complient with this draft/RFC?

> new authentication scheme?

It is strange that we are approching the problem from the other way
around.

A  foregin agent  can be  configured to make  a  new feature mandatory
(e.g., reverse tunnenling  or chanllenge response)  but  not the other
way around. And if configured to make something mandatory and does not
have  the required  information  in the  registration message  then FA
should indicate  to the mobile  of it (eg.    saying that a pirticular
feature  is  mandatory  and    the  mobile   did  not    include  this
information).  This way  backward  compatibility   and flexibility  is
acheived to some extent.

Also, in the future if we want to have a different authentication
mechanisim by having another extension to the the Router Discovery
qProtocol, the above method will make it easy (accoriding to the
current wording it may be hard to make them co-exist with the FA
challenge).

> Why should we, the Mobile IP WG, state that it is ok to make use of

To   my knowledge  only  protocol  RFC2607    talks  about  in roaming
envoirnments is RADIUS.  The problems are   also very bussniess  model
dependent.

> RADIUS in a roaming environment, then the draft DOES allow it.

RADIUS is being used in Proxy environemnts currently. For roaming and
wholesale dial.

Please see
http://www.ietf.org/internet-drafts/draft-ietf-radius-radius-v2-01.tx
which is clarifications to RFC2138 for use of RADIUS in Proxy
environments.

I don't see why Mobile IP WG should limit the use of RADIUS.

thanks
Gopal