INTERNET-DRAFT Vipul Gupta
SUN Microsystems, Inc
Jun 22, 1998
Inline Security Parameter Payload for Mobile IP
<draft-gupta-mobileip-inline-secparams-00.txt>
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [Brad96]. Internet Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and working groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo proposes a new payload extension for Mobile IP registration
requests and replies. It allows security parameters (except for any
secret keys), typically associated with a Security Parmaeter Index
(SPI), to be carried in-line with a Mobile IP authentication
extensions. The payload simplifies the use of public-key
authentication with Mobile IP by allowing inline exchange of
certificates. It even allows mixing of secret-key and public-key
based mechanisms in different authentication extensions within the
same Mobile IP message.
1. Introduction:
Mobile IP [Perk96] allows a mobile node to be reachable at the same
IP address (called its home address) even as it changes its point of
attachment to the Internet. Transport layer connections are
maintained across moves and all this is accomplished without the need
to propagate host-specific routes throughout the Internet routing
fabric.
Gupta Inline Security Parameter Payload [Page 1]
INTERNET-DRAFT Expires December, 1999 June 1999
A mobile node (MN) visiting a foreign network chooses a care-of
address on that subnet and registers it with its home agent (HA), a
special entity residing on its home subnet. The home agent intercepts
IP packets meant for the mobile node and tunnels them to the
registered care-of address. Tunneling refers to the process of
enclosing the original datagram, as data, inside another datagram
with a new IP header. The destination field in the outer IP header
contains the care-of address -- a topologically significant address
-- to which standard IP routing mechanisms can deliver packets. The
care-of address may belong to a specially designated node, a foreign
agent (FA), or may be acquired (perhaps temporarily) by the mobile
node, e.g. through DHCP or PPP. In the latter case, a mobile node is
said to have a co-located care-of address. At the tunnel endpoint,
the outer IP header is removed to recover the original IP packet
which is then delivered to the mobile node.
To prevent a malicious node from remotely redirecting another node's
traffic, registration requests and replies must be authenticated. The
base protocol [Perk96] describes the use of a keyed hash (MD5 in
prefix-suffix mode) for authentication. A more recent draft [Jaco99]
describes how public-key based authentication mechanisms may be used
with Mobile IP. As currently defined, the draft does not allow mixing
of public-key and secret-key based authentication mechanisms in the
same message nor does it support public-key certificates to be
exchanged as part of the Mobile IP messages. The inline security
parmaeter payload described below provides these features.
2. Inline Security Parameter Payload
This memo defines a new Mobile IP extension shown in Figure 1 which
is identified by a value of TBD in the Type field. Unlike other
extensions, this one uses two bytes for the Length field since its
length may exceed 255. The Length field contains the length of the
entire extension (in bytes) excluding the Type and Length fields.
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 |RDM| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID Type | Key ID Value ... (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
This extension MUST be followed immediately by one of the three
authentication extensions defined in RFC 2002: (a) MN-HA (b) HA-FA or
(c) FA-MN. That authentication extension MUST used an SPI value of
TBD to indicate that security parameters needed to verify its
authenticator are carried in-line as part of the immediately
Gupta Inline Security Parameter Payload [Page 2]
INTERNET-DRAFT Expires December, 1999 June 1999
preceeding inline security parameter payload.
The two-bit field marked RDM (Replay Detection Mechanism) indicates
the style of replay protection in use. This field MUST be zero when
the next extension is either a HA-FA authentication extension or a
FA-MN authentication extension. A non-zero value is allowed only if
this extension is followed by a MN-HA authentication extension. A
value of 01 indicates Timestamp-based replay protection and 10
indicates nonce-based replay protection.
The Algorithm field determines which of several secret-key or public-
key based authentication algorithms is used to compute the
authenticator information in the immediately following authentication
extension.
The following algorithms are supported (Public-key algorithms are
identified by an asterisk next to their name):
Algorithm
field Description Reference
----- ----------- ---------
1 HMAC-MD5 keyed hash [Rive92], [KBC97]
2 HMAC-SHA keyed hash [NIS94a], [KBC97]
3 Keyed hash using MD5 [RFC 2002]
in prefix-suffix mode
4 DSA* signature [NIS94b]
5 RSA-MD5* RSA encryption [RSA78]
of MD5 hash
This payload does not need to define distinct algorithm types for
different key sizes because key size information is implicit in the
Key Identifier (see below).
The payload also includes a Key Identifier that is used by the
receiver to look up the secret-key or public-key needed to verify the
corresponding authentication extension. Several different types of
Key IDs are supported.
The Key ID field is composed of two sub-fields:
Key ID Type This identifies the type of Key ID
information carried in the Key ID Value.
Key ID Value Contains the actual Key ID which
identifies either a secret key or a
public key needed to verify the
authenticator.
Gupta Inline Security Parameter Payload [Page 3]
INTERNET-DRAFT Expires December, 1999 June 1999
The following Key ID Types are defined.
Key ID
Type Description
----- -----------
RESVD (0) Reserved
OPAQUE (1) Indicates that the Key ID Value contains
an opaque value. How the receiver uses it
to look up a key is entirely a local matter
at the receiver. The presumption here is
that the sender and receiver have a previously
agreed method of mapping the opaque key ID
value to a key.
X509_CERT (2) Indicates that the Key ID Value subfield
contains a DER encoding of an X.509 certificate.
The public key contained in the certificate MUST
be for the same algorithm as indicated in the
Algorithm field. For example, if the Algorithm
field indicates DSA, the certificate MUST
include a DSA public key. Similarly, if the
Algorithm field indicates RSA-MD5, the
certificate MUST include an RSA public key.
After verifying the authenticity of the
certificate, the receiver SHOULD cache the
included public key in order to speed up
verification of subsequent messages from the
same sender.
X509_CERT_CHAIN Indicates that the Key ID Value subfield
(3) contains a chain of X.509 certificates.
This is useful if the receiver may not
have the authenticated public key of the
sender's certifying authority and may
need to follow a certificate chain to
establish the required trust.
Gupta Inline Security Parameter Payload [Page 4]
INTERNET-DRAFT Expires December, 1999 June 1999
CERT_MD5_HASH Indicates that the Key ID Value is the
(4) MD5 hash of a certificate. This is useful
in situations where the sender has reason
to believe that the corresponding
certificate is already available to the
receiver (e.g. it may have been sent in
a previous message or the receiver is known
to have access to a certificate repository
containing the sender's certificate). Due to
the collision resistance property of MD5, the
hash identifies a unique certificate with a high
degree of confidence. Sending the hash (16
bytes) rather than the actual certificate
results in smaller messages.
5 - 255 RESERVED
3. Authenticator computation and verification
The computation and verification of the Authenticator in the
immediately following authentication extension depends on the type of
the authentication Algorithm.
When the Algorithm is one of HMAC-MD5 or HMAC-SHA1, the authenticator
is computed using the HMAC generation algorithm with the MD5 [Rive2]
or SHA [NIS94a] hash functions as described in [KBC97]. When the
Algorithm is DSS [NIS94b], the authenticator contains the DER
encoding of two 20 byte numbers (r followed by s) representing the
DSA signature. When the Algorithm is RSA-MD5, the authenticator
contains the RSA encryption output (using the sender's private key)
of an MD5 hash. In the case of DSS and RSA-MD5, it is the public-key
corresponding to the private-key used for signing that MUST be
identified in the Key ID field.
The input for these computations is the same. It is the entire Mobile
IP message to be protected upto and including the type, length and
SPI fields in the authentication extension. This scope of coverage is
the same as defined previously in RFC 2002.
4. Security Considerations
This document describes a new security parameter payload for use with
Mobile IP authentication extensions. It allows the use of both
secret-key and public-key based methods (MACs and signatures) for
authenticating Mobile IP registration requests and replies. This
document does not address message confidentiality.
Gupta Inline Security Parameter Payload [Page 5]
INTERNET-DRAFT Expires December, 1999 June 1999
5. Revision History
Version Date Comments
------- ---- --------
00 Jun 23, 1998 Created initial version.
References
[Brad96] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, Oct. 1996.
[Jaco99] Jacobs, S., "Mobile IP Public Key Based Authentication",
Internet draft <draft-jacobs-mobileip-pki-auth-02.txt>,
work in progress, Mar. 1999.
[KBC97] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC:
Keyed-Hashing for Message Authentication," RFC 2104,
Feb. 1997.
[NIS94a] NIST, "Secure Hash Standard", FIPS 180-1, National
Institute of Standards and Technology, U.S. Department of
Commerce, May 1994.
[NIS94b] NIST, "Digital Signature Standard", FIPS 186, National
Institute of Standards and Technology, U.S. Department
of Commerce, May, 1994.
[Perk96] Perkins, C. (Editor), "IP Mobility Support", RFC 2002,
Oct. 1996.
[Rive92] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
Apr. 1992.
[RSA78] Rivest, R., Shamir, A., and Adleman, L., "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM, v. 21, n. 2,
Feb. 1978.
Author's Address
Vipul Gupta
Sun Microsystems, Inc.
901 San Antonio Rd.
Palo Alto, CA 94303
Tel: (650) 786 3614
Fax: (650) 786 6445
EMail: vipul.gupta@eng.sun.com
Gupta Inline Security Parameter Payload [Page 6]
INTERNET-DRAFT Expires December, 1999 June 1999
Gupta Inline Security Parameter Payload [Page 7]