Subject: (mobile-ip) New Mobile IPv6 Internet-Draft submitted

From: Dave Johnson <[email-masked]>
Date: Fri, 21 Nov 1997 17:01:04 -0500

I have submitted a new version of the Mobile IPv6 Internet-Draft for
publication before the Washington, DC IETF meeting.  This will be
draft-ietf-mobileip-ipv6-04.txt.  This version cleans up a number of
important things here and there in both the protocol and its
presentation.  The major differences between this version and the
previous version include:

    -  Added a statement of some non-goals of the protocol in Section 1.

    -  Added definition for "home link" and "home subnet prefix",
       replacing the old term "home subnet".  The new terms "foreign
       link" and "foreign subnet prefix" likewise replace the old term
       "foreign subnet".  This change is more in line with current IPv6
       terminology.

    -  Moved the "Comparison with Mobile IP for IPv4" section (now
       Section 2) to earlier in the document to allow those familiar
       with Mobile IPv4 to quickly see the major differences.

    -  Added specific language in Section overview listing the fields
       conceptually present in each Binding Cache entry and in each
       Binding Update List entry.

    -  Changed the Option Type values for the Binding Acknowledgement
       and Binding Request options such that they now indicate that the
       option should be ignored if not recognized, rather than returning
       an ICMP error message as they were previously defined.

    -  Increased the Lifetime field in a Binding Update from 16 bits
       to 32 bits, to allow consistency with other lifetime values
       used in IPv6 (e.g., the lifetime of a subnet prefix in Neighbor
       Discovery [11]).  Similarly increased the Lifetime and Refresh
       fields in the Binding Acknowledgement from 16 bits to 32 bits.

    -  Replaced the Home Link-Local Address Present (L) bit and the
       Home Link-Local Address field in the Binding Update with a new
       mechanism implemented by the ID Length field in the Binding
       Update.  By specifying the length of the interface identifier in
       its home address in this field, the mobile node can request its
       home agent to essentially fully participate in Neighbor Discovery
       on the home link as a proxy for the mobile node, while the mobile
       node is away from home.

    -  Clarified that packets addressed to a mobile node's link-local
       address or site-local address are not forwarded to the mobile
       node while away from home.  When intercepted by the mobile node's
       home agent, such packets now cause the home agent to return an
       ICMP Destination Unreachable, Code 3, message to the packet's
       Source Address (unless this Source Address is a multicast
       address).  As the use of link-local addresses or site-local
       addresses evolves over time in IPv6, this disposition of such
       packets may need to change, however.

    -  Added a discussion of sending Binding Requests in Section 7.6,
       and added a discussion of receiving Binding Requests in
       Section 9.11.

    -  Change the requirement for sending a Binding Update to a mobile
       node's previous default router in Section 9.6 from "SHOULD" to
       "MAY".

    -  Added Section 12 on "IANA Considerations".

    -  Replaced the description of specification language keywords,
       "MUST", "MAY", "SHOULD", etc., in Section 3.3 with the new
       standard reference to RFC 2119.

    -  Updated the References to point to the most recent version of
       each cited RFC or Internet-Draft.

I have also put a copy of this draft on my ftp server, so you can get
it before it works its way through to the official directories.  The
new version of the draft is available at

        ftp://ftp.monarch.cs.cmu.edu/pub/internet-drafts/
            draft-ietf-mobileip-ipv6-04.txt

Comments on this draft should be sent to the Mobile IP mailing list
at [email-masked].  We will be discussing this draft during
IETF at the Mobile IP working group meeting on Monday evening,
December 8, 7:30-10:00 pm.

					Dave
-----------------------------------------------------------------------------
IETF Mobile IP Working Group Mailing List - Archives:  software.watson.ibm.com
Unsubscribe:	unsubscribe mobile-ip		(as message body, not subject)
Direct all administrative requests to [email-masked]

---

From: zhong chen <[email-masked]>
Date: Mon, 1 Dec 1997 13:07:29 -0800 (PST)

Mobile IP Authentication -- A Scalable Solution

				 Zhong Chen

				Dec. 1, 1997

1. Introduction

Mobile IP Authentication is non-trivial. When the Mobile Node is at home,
authentication of deregistration messages is easy. This article focuses mainly
on the problem of authentication when the Mobile Node is temporarily located
in a Foreign network and the authentication of registration messages between
the Mobile Node/Home Agent and the Foreign Agent is required or desired.

In this article, we try to solve the problem by means of Mobile IP protocol 
itself, instead of using any other protocol to negotiate mobility security
associations prior to or during mobile registration.

A scalable solution inevitably involves the use of public-key cryptosystem
based authentication schemes. However, the cost of using public-key 
cryptography can be very high. We try to minimize this cost by a careful 
analysis of security needs and use public-key cryptography as little as
possible.

For the first round of registration, mobility entities use public-key 
cryptography to authenticate registration messages. At the same time, mobility
entities also include key-exchange extensions inside registration messages to
setup necessary symmetric session keys for subsequent registrations. Session
keys remain in effect for a valid lifetime. Public-key cryptography is used
in a long-term basis to setup short-term session keys when necessary.

In order to use public-key cryptography based authentication without first
negotiate mobility security associations prior to mobile registration, it is
advised that mobility entities use "well-known" SPI values for authentication
extensions carrying digital signatures. Otherwise, message receivers have no
way to process these authentication extensions without necessary pre-existent
security contexts.

Throughout this article, Mobile-Foreign security relationship and Foreign-Home
security relationship are assumed to be bi-directional.

By designing the following protocol, the author of this article assumes the 
Foreign Agent and Home Agent have direct Internet connectivity and thus can 
verifies digital signatures in whatever method possible.

The protocol does not try to solve the problem of denial-of-service
attack.

2. The Protocol

Here is a step-by-step description of the procedures needed to use public-key
cryptography and key-exchange extensions in Mobile IP protocol to solve Mobile
IP authentication problem in a scalable basis:

1). If authentication is required or desired, the Mobile Node computes a key-
    exchange key, chooses a SPI value and constructs a registration request
    message with the following Foreign-Agent-specific extensions and sends it
    to the Foreign Agent:

	* a Mobile-Foreign key-exchange extension (includes Mobile Node 
	  chosen SPI value)
	* a Mobile-Foreign authentication extension with a digital signature 
	  as the authenticator (signed with Mobile Node's private key)

2). Upon receipt of the Mobile Node registration request, the Foreign Agent
    manages to obtain Mobile Node's public key and verifies Mobile Node's
    signature. If everything is fine, the Foreign Agent consumes all Foreign-
    Agent-specific extensions, computes a key-exchange key, chooses a SPI value
    and add the following extensions to the registration request before 
    forwarding it to the Home Agent:

	* a Foreign-Home key-exchange extension (includes Foreign Agent 
	  chosen SPI value)
	* a Foreign-Home authentication extension with a digital signature 
	  as the authenticator (signed with Foreign Agent's private key)

3). Upon receipt of the Foreign Agent forwarded registration request, the Home
    Agent manages to obtain Foreign Agent's public key and verifies Foreign
    Agent's signature. If everything is fine (includes Mobile-Home security
    check, Access Control List lookup, etc.), the Home Agent setups a tunnel
    for the Mobile Node and sends a registration reply with a positive reply
    code to the Mobile Node, forwarded by the Foreign Agent. Otherwise, a 
    negative reply should be sent. If authentication is required or desired, 
    the Home Agent should compute its own key-exchange components, form a 
    session key using Foreign Agent's key-exchange components just received, 
    and use this new session key to authenticate its reply message immediately.
    The following Foreign-Agent-specific extensions should be sent along with
    the registration reply:

	* a Foreign-Home key-exchange extension
	* a Foreign-Home authentication extension with the authenticator 
	  computed by using the new Foreign-Home session key

4). Upon receipt of the Home Agent reply message, the Foreign Agent first uses
    Home Agent's key-exchange extension, together with its own key-exchange
    components, to form the session key being used by the Home Agent, and then 
    uses this new session key to verifies Home Agent's authentication extension.
    If everything is fine, the Foreign Agent further forwards the reply message
    to the Mobile Node. Before forwarding, the Foreign Agent needs also to
    compute its own key-exchange components to be used with the Mobile Node, 
    construct a session key using Mobile Node's key-exchange components 
    previously received, and use this new session key to authenticate its 
    forwarded reply to the Mobile Node. The following extensions should be 
    sent in place of Foreign Agent contributed extensions:

	* a Mobile-Foreign key-exchange extension
	* a Mobile-Foreign authentication extension with the authenticator
	  computed by using the new Mobile-Foreign session key

5). Upon receipt of the Foreign Agent forwarded registration reply, the Mobile
    Node first uses Foreign Agent's key-exchange extension, together with its
    own key-exchange components, to form the session key being used by the
    Foreign Agent, and then uses this new session key to verifies Foreign 
    Agent's authentication extension. If the Mobile-Home security check and
    all other sanity checks also succeed, a registration is finished
    successfully. 

3. Summary of Key Points:

    * Public-key cryptography is used twice. Registration requests are
      authenticated using private-public key pairs.

    * Key-exchange keys are exchanged in registration messages to setup
      secret session keys for immediate and future use.

    * Secret-key cryptography is used at its earliest possible time in the 
      registration process. Registration replies are authenticated using 
      secret session keys.

  *** The Mobile Node does not have to verify Foreign Agent's signature,
      this solves a big problem that the Mobile Node has no Internet 
      connectivity to other hosts than the Foreign Agent before registration 
      completes.

    * Mobile Node's identity is verified by the Foreign Agent from its
      signature.

    * Foreign Agent's identity is verified by the Home Agent from its
      signature.

  *** By receiving a positive reply from its Home Agent, the Mobile Node
      assumes Foreign Agent's identity has been verified by its Home Agent 
      and does not care about Foreign Agent's identity itself.

    * Since Mobile Node and Home Agent belong together, the Foreign Agent
      cares only about Mobile Node's identity, it does not cares about
      Home Agent's identity. If it does care, the above protocol can be
      modified to use public-key cryptography one more time at step 3 when 
      the Home Agent sends a registration reply to the Foreign Agent.

4. Further considerations:

    * This article does not specify any method to propagate security policies
      among mobility entities and leaves it for future study. At a minimum,
      the Foreign Agent can advertise its requirement of authentication
      of Mobile Node messages via "Agent Advertisements" and the Mobile Node
      can inform the Foreign Agent about Home Agent's requirement of
      authentication of Foreign Agent messages via the "key-exchange 
      extension".

    * Due to the unreliability of UDP protocol and the fact that mobility
      entities can lost security context about corresponding mobility 
      entities at any time without knowledge of corresponding mobility
      entities, the Mobile Node should be ready to initialize a public-key
      cryptography based registration process at any time when a negative
      reply indicates that such an error has occurred, in addition to
      regular periodic re-establishments of secret session keys.

References

  [1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
  [2] Housley, R., Ford, W., Polk, W. and Solo, D., "Internet Public 
      Key Infrastructure", <draft-ietf-pkix-ipki-part1-05.txt>, July 1997.
  [3] Eastlake, D. and Kaufman, C., "Domain Name System Security Extensions", 
      RFC 2065, January 1997.

***********************************************
Zhong CHEN

Dept. of Computer Science
Portland State University
P.O.Box 751
Portland, OR 97207

Tel: (503)725,4138(O)
http://www.cs.pdx.edu/~zchen/
***********************************************