Subject: [mobile-ip] Strawman generic authentication framework for Mobile IP

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Sep 2001 10:47:28 +0200

The discussion in the "Concerns/comments for aaa-keys and gen-key"
thread mentioned a multi round trip Mobile IP protocol, for
negotiation authentication algorithm/parameters.  This is more or less
what I've been thinking about for the past few days.  This would allow
for non-AAA/Diameter solutions within Mobile IP which I believe there
are applications for.

I'm including my outline of how this should work below... any comments
most welcome, in particular on how this would affect Mobile IP
implementations since I am no expert on Mobile IP.

Thanks,
Simon

Strawman generic authentication framework for Mobile IP
-------------------------------------------------------

The purpose of this note is to explore how existing authentication
methods can be used directly in Mobile IP.  For example, how TLS, EAP,
SASL or CHAP could be used directly in Mobile IP.

The goal is to be able to provide user (or device) authentication of
the Mobile Node to a Foreign Agent or Home Agent within the Mobile IP
protocol (the Registration Request and Registration Response packets),
and optionally establish keying material for IP encryption.

A side effect of this is that Mobile IP is enhanced with a security
framework that is able to negotiate the algorithm to use, instead of
the current situation where Mobile Nodes, Foreign Agents and Home
Agents need to be setup with this information in advance (or somehow
use Diameter for this).

We begin by identifying some problems:
--------------------------------------

   * Mobile IP does not obviously describe how authentication
     mechanisms that need more than a simple two round packet exchange
     can be used in Mobile IP. (RFC 2002 and Son-of-RFC2002.)  This is
     the main problem we address.

   * The Mobile IP Challenge/Response Extensions (RFC 3012) seems to
     be an attempt to make the authentication in Mobile IP more
     generic.  This is accomplished by using the same packet format
     for authentication of any entity, instead of using special
     packets, one for the Home Agent, one for the Foreign Agent and
     one for the Mobile Node.

     However, the way in which the Authenticator packets are exchange
     is not changed.  Only a generic packet format is defined, but a
     generic interaction description is not included.  This "generic
     interaction description" should include how the authentication
     mechanism can signal "continue", "abort" and "success" to the
     other entity.  Only "abort" and "success" is possible now, using
     the base RFC 2002 spec.

     The Generalized Key Distribution Extension is similar, it only
     describes a generic packet format without discussing a generic
     way in which the packets can be used.

Outline of suggested specification:
-----------------------------------

A specification may introduce new Mobile IP error codes that should be
used as indicators that the other entity that additional authenticator
packets needs to be exchanges before it can complete.  Examples:

   Registration denied by the foreign agent:

...
       89 Foreign Agent needs more authentication data before it can proceed

   Registration denied by the home agent:

...
      142 Home Agent needs more authentication data before it can proceed.

The individual authenticator mechanisms could be allocated in the
0-255 SPI IANA space as defined in RFC 3012, examples:

SPI Values for the Mobile IP Reserved SPIs:

	0 Reserved                                            [RFC3012]
        1 Reserved                                            [RFC3012]
        2 CHAP                                                [RFC3012]
	3 TLS
	4 EAP
	5 PKI
	...

(Where 5 could be ideas similar to what is in
draft-jacobs-mobileip-pki-auth-03.txt.)

Example:
--------

This is an example of how TLS can be used to authenticate a user to a
Mobile IP infrastructure.  Note that the TLS_SPI of 4 and Continuation
Error Code of 137 are just examples, they are not official in any way.

        Mobile Node                            Home Agent

{Mobile IP Registration Request:
Mobile-Home Auth Extension:
SPI=4 (TLS_SPI), Authenticator:
TLS Client Hello, ...}

                                        {Mobile IP Registration Reply:
                                        Code=137 (Continue Authentication)
					Mobile-Home Auth Extension:
					SPI=4 (TLS_SPI), Authenticator:
					TLS Server Hello, ...}

{Mobile IP Registration Request:
Mobile-Home Auth Extension:
SPI=4 (TLS_SPI), Authenticator:
TLS Client Key Exchange, ...}
                                    .
                                    .
                                    .

                                        {Mobile IP Registration Reply:
                                        Code=0 (Registration Accepted)
					Mobile-Home Auth Extension:
					SPI=4 (TLS_SPI), Authenticator:
					TLS Server Finished, ...}

Open Issues:
------------

One needs to investigate the need for a CHALLENGE extension such as
the one used in RFC 3012 to prevent replay-attacks of the registration
requests, or at least a identification scheme to make it possible to
separate between multiple authentication attempts.

It is not clear to me how sending multiple registration requests would
affect Mobile IP implementations, especially how the Foreign Agent
would react.  Maybe the approach above interacts badly with the design
of Mobile IP.