Subject: [MOBILE-IP] Latest Challenge draft issued

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

All,

The challenge/response draft has just been sent to the IETF secretariat to
be posted in the IETF ftp archives. For those that want to get their virtual
hands on it before the announcement, you can get it at:

www.diameter.org/draft-ietf-mobileip-challenge-05.txt

PatC

---

From: Gopal Dommety <[email-masked]>
Date: Thu, 21 Oct 1999 16:38:33 -0700

Hello Charlie and Pat:

I have some questions based on 04.txt (see below). Would appreciate if
you could address them.

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???

   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?

   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.

   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.

   to interact with the verification infrastructure.

   Since the Challenge extension, and the authentication extension that
   is used by the Mobile Node to satisfy the challenge, both follow
   the Mobile-Home Authentication extension whenever the latter is
   present, the Foreign Agent MAY remove the Challenge Extension and
   the applicable authentication from the Registration Request without

Perkins, Calhoun             Expires 25 April 2000              [Page 3]

Internet Draft       Mobile IP Challenge/Response        25 October 1999

   disturbing the authentication value computed by the Mobile Node for
   use by the Home Agent.

   If the Foreign Agent does not remove those extensions, then the
   Foreign Agent SHOULD store the Challenge value as part of the pending
   registration request list [11].  Also in this case, the Foreign Agent
   MUST reject any Registration Reply message coming from the Home Agent
   that does not also include the Challenge Extension with the same
   Challenge Value that was included in the Registration Request.  The
   Foreign Agent MUST send the rejected Registration message to the
   mobile node, and change the status in the Registration Reply to the
   value MISSING_CHALLENGE (see section 6).

   If the Foreign Agent does remove the Challenge extension and
   applicable authentication from the Registration Request message,
   then it SHOULD insert the Identification field from the Registration
   Request message along with its record-keeping information about the
   particular Mobile Node in order to protect against replays.

3.3. Home Agent Processing for the Challenge Extensions

   If the Home Agent receives a Registration Request with the MN-FA
   Challenge extension, and recognizes the extension, the Home Agent
   MUST include the Challenge extension in the Registration Reply.
   The Challenge Extension SHOULD be included before the Mobile-Home
   Authentication extension.

   Since the extension type for the Challenge extension is within the
   range 128-255, the Home Agent MUST process such a Registration
   Request even if it does not recognize the Challenge extension [11].
   In this case, the Home Agent will send a Registration Reply to the
   Foreign Agent that does not include the Challenge extension.

4. Mobile IP Registration Extensions

   This section specifies new Mobile IP Registration Extensions that are
   used to satisfy a Challenge in an Agent Advertisement.

4.1. MN-FA Challenge Extension

   The Challenge extension to the Registration Request message is used
   to indicate the challenge that the mobile node is attempting to
   satisfy.

Perkins, Calhoun             Expires 25 April 2000              [Page 4]

Internet Draft       Mobile IP Challenge/Response        25 October 1999

       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     |         Challenge...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2: The MN-FA Challenge Extension

      Type        132 (skippable) (see [11])

      Length      MUST be at least 16

      Challenge   The Challenge field is copied from the Challenge field
                  found in the Agent Advertisement Challenge extension
                  (see section 2).

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.

   (section 4.3) whenever the Challenge extension is present.

       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

Perkins, Calhoun             Expires 25 April 2000              [Page 5]

Internet Draft       Mobile IP Challenge/Response        25 October 1999

      Type            36 (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 || Preceding Mobile IP data || Type, Length, SPI || Key

   where the Type, Length, and SPI are as shown above.  Each mobile node
   MUST support the ability to produce the authenticator by using MD5 as
   shown (known as "prefix+suffix" mode).  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.

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.