HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 00:12:35 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 29 Jun 1999 16:18:58 GMT ETag: "2e6f22-3826-3778f1f2" Accept-Ranges: bytes Content-Length: 14374 Connection: close Content-Type: text/plain INTERNET-DRAFT Vipul Gupta SUN Microsystems, Inc Jun 22, 1998 Inline Security Parameter Payload for Mobile IP 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 , 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]