IP Routing for Wireless/Mobile Hosts (mobileip) WG S. Jacobs, S. Belgard
INTERNET DRAFT Verizon Laboratories
Date: 09 July 2001
Expires: January 2002
Mobile IP Public Key Based Authentication
<draft-jacobs-mobileip-pki-auth-03.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its 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 document proposes an extension to the Mobile IP base protocol
(RFC 2002) to allow Mobile Nodes (Hosts) and Mobility Agents (both
home network and foreign network) to use X.509 digital certificates,
public keys and digital signatures as the basis of authenticating
Mobile IP control messages in addition to secret key authentication.
The use of these mechanisms will allow Mobile IP to scale from small
research environments to potentially millions of mobile nodes across
thousands of networks owned-operated by different organizations and
service providers. A Public Key Infrastructure is proposed that
focuses specifically on authentication of Mobile IP knowledgeable
nodes, NOT general use for authenticating individuals.
1. Introduction
The Mobile IP base protocol [RFC2002] provides a scalable mechanism
for node mobility. When examining the various types of Mobile IP
deployments being considered, one sees significantly different
networking environments. Research test beds are relatively benign
environments, provide network bandwidth from a few Kbps to Gbps within
a single organization. Office and warehouse networks face a greater
level of threats, are typically a mixture of wired and wireless media
Jacobs, Belgard [Page 1]
INTERNET DRAFT 09 July 2001
with bandwidth ranging from Mbps to Gpbs, and may span a number of
organizations. Service provider deployments are focused on a wireless
environment, face many possible threats, provide bandwidth from
4.8Kbps to a few 100Kbps, interoperability across many organizations,
and assure the ability to account and bill for services rendered.
The number and frequency of protocol control messages has a direct
impact on a protocol like Mobile IP; especially for frequently roaming
nodes. The impact of control message size and control message size
frequency have a direct impact on network bandwidth. As available
network bandwidth decreases, network control overhead needs to be
minimized. Frequent network control messages increase network
overhead. Mobile IP deployment environments face different types of
threats and associated degrees of risk ranging from very few threats
and low risks to many threats and very high risks. A Mobile IP
deploying organization faces a trade-off between their expected
threats, the degree of risk acceptable and the cost in network
security overhead necessary to mitigate risk in a specific threat
context.
There are a number of Mobile IP control message authentication
methodologies, such as manually distributed Secret Keys, IPsec
negotiated security associations, AAA negotiated security
associations, self-signed Certificates containing Public Keys, and
CA signed Certificates containing Public Keys. For each authentication
method there are advantages and disadvantages (trade-offs) between
bandwidth consumed, scaleability, complexity and performance. All
authentication solutions are based on arriving at a compromise between
these trade-offs.
As the number of nodes deployed increases, the number of secret keys
increases even faster, namely ((#nodes * (#nodes-1))**2)/2, which
increases complexity yet have a positive impact on performance as they
are relatively easy to compute and process. With public keys, the
number of keys needed = the number of nodes, reducing complexity yet
have a negative impact on performance as they are more expensive to
compute and process than secret keys.
Manual key distribution approaches necessitate distributing key
information to all nodes prior to deployment, reducing scaleability,
yet have no impact on network overhead. Dynamic key distribution
approaches eliminate pre-deployment key distribution, thereby
increasing scaleability, yet increase network overhead as keys are
established/exchanged over the network.
Jacobs, Belgard [Page 2]
INTERNET DRAFT 09 July 2001
Dynamic key distribution and security association negotiation methods
vary greatly regarding:
- number of messages used
- complexity of supporting protocols
- number of participants involved
- supporting infrastructure required
- computing resources consumed
- robustness and integrity of resulting security associations.
The primary dynamic approaches under consideration are:
- IPsec protocols
- Authentication, Authorization and Accounting Protocols (AAA).
The IPsec suite of IKE and ISAKMP provide a general purpose approach to
establishing and negotiating Security Associations (SAs) between
communicating systems on a peer-to-peer basis. The use of this
authentication method with Mobile IP will:
- increase the number of discreet messages exchanged between a Mobile Node
(MN) and a Foreign Agent (FA) by three (3) if "aggressive mode" is used or
by six (6) messages if "main mode" is used for IKE phase one. A like
number of extra messages will have to be exchanged between the FA and the
MN's Home Agent (HA), as well as between the MN and its HA. IKE phase two
communication adds an additional 3 messages between MN and FA, FA and HA,
and HA and MN. Using IKE results in at least 18, and as many as 27,
additional messages, beyond those directly necessary for Mobile IP, being
exchanged to establish IPsec SAs.
- require the exchange of Public key digital certificates, as part of the
IKE protocol, unless these are pre-distributed. Given that an MN does not
necessarily know apriori where it will roam, pre-distributing certificates
to FAs becomes nearly impossible.
- regardless of which IKE mode used, each network node will have to either
generate/verify one digital signature or perform one public/private key
encryption/decryption as part of the IKE phase one protocol.
- The IKE protocol does not include certificate validation or certificate
revocation and the network overhead managing certificates.
The leading AAA approach is based on the DIAMETER protocol. DIAMETER:
- does not increase the number of discreet messages exchanged between a
Mobile Node (MN) and a Foreign Agent (FA) or between the MN and its HA.
- requires the use of AAA Servers to perform the actual authentication
function for FAs and HAs increasing the number of required participants
significantly.
- primarily focuses on the use of secret keys for establishing identity
authenticity and expects the AAA servers to dynamically generate these
secret keys in real-time as needed.
- does not provide a secure method for distributing the dynamically
generated secret keys unless one has pre-distributed static secret keys to
all mobility aware nodes.
Jacobs, Belgard [Page 3]
INTERNET DRAFT 09 July 2001
This document proposes an extension to the Mobile IP base protocol that
defines how Mobile Nodes (MNs) and Mobility Agents (both HAs and FAs) may:
- use public key based authentication via digital signatures.
- use X.509 digital certificates
- issued by Certificate Authorities (CAs)
- issued by the subject of the certificate (self-signed certificates for
a PGP-like informal web of trust)
- use a Network Access Identifier (NAI) for identifying mobile nodes and
mobility agents
- ahndle digital certificate revocation and verification.
These Mobile IP authentication extensions are designed to minimally
change the Mobile IP defined in [RFC-2002]. The extensions make use
of a few reserved fields in the existing Mobile IP message definitions.
Given the increased functionality of this approach the RFC-2002
authentication extension has been modified to accommodate different
authentication types, different sizes of authenticators (digital signatures)
and the use of Network Access Identifier for identifying mobile nodes and
mobility agents. These changes to Mobile IP do not prevent using Mobile IP
with DHCP on visited networks (if one is willing to forgo visited network
authentication, access control and non-repudiation). The security benefit
from these extensions is achieved when using Foreign Agents.
2. Terminology
Certification Authority (CA)
A third party trusted by one or more users to create and assign
digital certificates.
Certificate-Revocation List (CRL)
A data structure that contains information about certificates
whose validity an issuer has prematurely revoked. The
information consists of an issuer name, the time of issue, the
next scheduled time of issue, and a list of certificate serial
numbers and their associated revocation times. The CRL is signed
by the issuer. The data structure is defined in [RFC1422]
Certificate Subject (Subject)
A Certificate Subject, or Subject, is the entity referred to by
the NAI contained within the Certificate.
Digital Certificate (Certificate)
A Digital Certificate, or Certificate, is a data structure
that binds an entity's NAI to a public key with a digital
signature. This data structure is defined in [X.509]. and
contains information, such as identify and public key, about
an entity where an authority, called a Certification Authority,
has cryptographicly linked the information together using a
digital signature.
Jacobs, Belgard [Page 4]
INTERNET DRAFT 09 July 2001
Digital Certification
Digital Certification is the mechanism in which a Certification
Authority (CA) "signs" a special data structure containing the
name of some entity, or Subject, and their public key in such a
way that anyone can "verify" that the message was signed by no
one other than the certification authority and thereby develop
trust in the subject's public key.
Digital Signature
the content to be signed is first reduced to a message digest
with a message-digest algorithm (such as MD5), and then the
octet string containing the message digest is encrypted with
the private key of the signer of the content.
Message-Digest Algorithm
A message-digest algorithm is a method of reducing a message of
Any length to a string of a fixed length, called the message
digest, in such a way that it is computationally infeasible to
find a collision (two messages with the same message digest) or
to find a message with a given, predetermined message digest.
MD2 and MD5 are message-digest algorithms described in
[RFC1319] and [RFC1321]. Each inputs an arbitrary message and
outputs a 128-bit message digest.
Mobile Security Association (MSA)
A collection of security contexts, between a pair of nodes,
which may be applied to Mobile IP control messages exchanged
between them. Each context indicates an authentication algorithm
and mode.
Network Access Identifier (NAI)
A string of octets as defined in [RFC2486] for identifying
mobile nodes and mobility agents.
Public-key algorithm
An algorithm for encrypting or decrypting data with a public or
Private key. When a private key is used to encrypt a message
digest the public-key algorithm is called a message-digest
encryption algorithm and the encrypted output is called a
Digital Signature. This algorithm transforms a message of any
length under a private key to a signature in such a way that it
is computationally infeasible to find two messages with the
same signature, to find a message with a given, predetermined
signature, or to find the signature of a given message without
knowledge of the private key. Typically, a digital signature is
created by computing a message digest on the message, then
encrypting the message digest with the private key.
Jacobs, Belgard [Page 5]
INTERNET DRAFT 09 July 2001
Public-key cryptography
Public-key cryptography is the technology first identified by
Diffie and Hellman [Diffie76] in which encryption and
Decryption involve different keys. The two keys are the public
key and the private key, and either can encrypt or decrypt
data. A user gives his or her public key to other users,
keeping the Private key to himself or herself.
RSA
RSA is a public-key algorithm invented by Rivest, Shamir, and
Adleman [RSA78] involving exponentiation modulo the product of
two large prime numbers. The difficulty of breaking RSA is
generally considered to be equal to the difficulty of factoring
integers that are the product of two large prime numbers of
approximately equal size.
Security Context
A security context between two nodes defines the manner in
which these two nodes choose to mutually authentication each
other, and indicates an authentication algorithm and mode.
Security Parameter Index (SPI)
An index, used with Secret Key authentication mechanisms,
identifying a security context between a pair of Nodes among the
contexts available.
Self-Signed Digital Certificate (Self-Signed Certificate)
A Digital Certificate, or Certificate, is a Digital Certificate
that has been signed by the entity to which the Certificate
appies to. This data structure is defined in [X.509] and
contains information, such as identify and public key, about an
entity where the entity itself has cryptographicly linked the
information together using a digital signature.
X.509 Digital Certificate
An X.509 Digital Certificate is a data structure that binds an
entity's NAI to a public key with a digital signature. This data
structure is defined in [X.509].
X.509 Digital Certification
X.509 Digital Certification is the mechanism in which a
Certification Authority (CA) "signs" a special data structure
containing the name of some entity, or Subject, and their public
key in such a way that anyone can "verify" that the message was
signed by no one other than the Certification Authority and
thereby develop trust in the subject's public key.
Jacobs, Belgard [Page 6]
INTERNET DRAFT 09 July 2001
3. Specification Language
This document uses the terms "MUST", "SHOULD", and "MAY" as defined
in RFC-2119, along with the negated forms of those terms.
4. Security Enhancement
The design goal of the approach presented herein is to add scaleable
strong authentication to Mobile IP. This approach works exactly the
same way as the base protocol except for the mechanism responsible for
generating/verifying message authenticators (digital signatures) and
the data structures supporting the proposed digital signature based
authenticators.
The Co-located Care-of Address (COA) mode (sometimes referred to as
"pop-up" mode) relies on the use of DHCP [RFC1541] which assumes that
nodes requesting DHCP assigned addresses either belong to the same
organization operating the DHCP server or these nodes will be
authenticated for network use outside of DHCP.
Each extended Mobile IP Node SHOULD be able to support multiple
authentication options ranging from simple to complex, while also
permitting the possibility of no authentication (the default mode).
Mobile IP messages between Mobile Nodes and Mobility Agents are
authenticated with an Authentication Extension. The Authentication
Extension identifies the Authentication type to be used and a
Security Context between a pair of Mobile IP Nodes and is fundamental
to defining the Mobility Security Association (MSA) between these
nodes. The Authentication Extension MAY be followed by a Certificate
Extension if the MSA, between the Mobile Nodes utilizes public key
based authentication and Certificates.
The Certificate Extension includes a copy, or copies, of Certificates
that bind system "distinguished names" to public keys using a digital
signature. A Certificate Extension will always contain at least one
Certificate which applies to the sender of a Mobile IP message. There
may also be present in the Certificate Extension, Certificates
belonging to one of more CAs. When Mobile Nodes share a common CA, the
Certificate of the common CA would appear in the Certificate
Extension. In the case where the communicating Nodes do not share a
common CA then the Certificate Extension may contain multiple CA
Certificates from which a trust hierarchy path Between the CA of one
Node and the CA of the other Node may be established.
Jacobs, Belgard [Page 7]
INTERNET DRAFT 09 July 2001
4.1. Message and Extension Formats
The changes described herein include:
- the use of a NAI extension with all MIP messages to identify the messages
sender via a unique Network Access Identifier indipendant of IP
addresses.
- a modified Advertisement extension that now includes authentication
information
- a modified Registration Request extension that identifies the form of
authentication
- a modified Registration Reply extension that identifies the form of
authentication
- a modified Authentication extension that may now include
public key digital signature authentication information
- a Network Access Identifier extension that contains a unique
identifier for Mobile IP aware nodes
- a Certificate extension that is used for exchanging X.509 digital
certificates
4.1.1. Mobility Agent Advertisement Extension
The Mobility Agent Advertisement Extension follows the ICMP Router
Advertisement fields. It is used to indicate that an ICMP Router
Advertisement message is also an Agent Advertisement being sent by a
mobility agent. The Mobility Agent Advertisement Extension is defined
as follows:
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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime |R|B|H|F|M|G|V|A| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 16 (Mobility Agent Advertisement)
Length Unchanged from base Mobile IP protocol.
Sequence Number Unchanged from base Mobile IP protocol.
Jacobs, Belgard [Page 8]
INTERNET DRAFT 09 July 2001
Registration Lifetime Unchanged from base Mobile IP protocol.
R bit Unchanged from base Mobile IP protocol.
B bit Unchanged from base Mobile IP protocol.
H bit Unchanged from base Mobile IP protocol.
F bit Unchanged from base Mobile IP protocol.
M bit Unchanged from base Mobile IP protocol.
G bit Unchanged from base Mobile IP protocol.
V bit Unchanged from base Mobile IP protocol.
A bit (New) Previously reserved in RFC-2002. If
bit not set then this is a
traditional RFC 2002 Advertisement
extension. If set then this is an
authenticated advertisement and is
followed by a Network Access
Identifier extension, Authentication
Extension, and Certificate extension.
Care-of Address(es) Unchanged from base Mobile IP protocol.
Extensions When A bit = 0, No extensions follow
When A bit = 1, Usage is as follows
- Foreign Agent Network Access Identifier
extension appended
- Foreign Agent Authentication extension
appended
- Foreign Agent Certificate extension is
appended
4.1.2. Registration Request Message
An MN registers with its HA using a Registration Request message so
that its HA can create or modify a mobility binding for that MN. The
Request MAY be relayed to the HA by an FA through which the MN is
registering. The UDP header is followed by the Mobile IP fields shown
below:
Jacobs, Belgard [Page 9]
INTERNET DRAFT 09 July 2001
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 |S|B|D|M|G|V|A|r| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 1 (Registration Request)
S bit Unchanged from base Mobile IP protocol.
B bit Unchanged from base Mobile IP protocol.
D bit Unchanged from base Mobile IP protocol.
M bit Unchanged from base Mobile IP protocol.
G bit Unchanged from base Mobile IP protocol.
V bit Unchanged from base Mobile IP protocol.
A bit (New) Previously reserved in RFC-2002. If
bit not set then this is a traditional
RFC 2002 Registration Request extension.
If set then this is a modified registration
request and is followed by a Network Access
Identifier extension, Authentication extension
And Certificate Extension.
r bit Unchanged from base Mobile IP protocol.
Lifetime Unchanged from base Mobile IP protocol.
Home Address Unchanged from base Mobile IP protocol.
Home Agent Unchanged from base Mobile IP protocol.
Care-of Address Unchanged from base Mobile IP protocol.
Jacobs, Belgard [Page 10]
INTERNET DRAFT 09 July 2001
Identification Unchanged from base Mobile IP protocol.
Extensions When A bit = 0,Usage is as follows between Mobile
Node and Foreign Agent
- RFC 2002 formatted Mobile Node Authentication
extension is appended.
When A bit = 0,Usage is as follows between
Foreign Agent and Home Agent
- RFC 2002 formatted Mobile Node Authentication
extension is appended.
- RFC 2002 formatted Foreign Agent
Authentication extension is appended.
When A bit = 1,Usage is as follows between Mobile
Node and Foreign Agent
- Mobile Node Network Access Identifier
extension is appended.
- Modified Mobile Node Authentication extension
is appended.
- Mobile Node Certificate extension is appended.
When A bit = 1,Usage is as follows between
Foreign Agent and Home Agent
- Mobile Node Network Access Identifier
extension is appended.
- Modified Mobile Node Authentication extension
is appended.
- Foreign Agent Network Access Identifier
extension is appended.
- Foreign Agent Authentication extension is
appended.
- Foreign Agent Certificate extension is
appended.
Jacobs, Belgard [Page 11]
INTERNET DRAFT 09 July 2001
4.1.3. Registration Reply
A mobility agent (FA or HA) returns a Registration Reply message to an
MN which was the source of a Registration Request message. The UDP
header is followed by the Mobile IP fields shown below:
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 |A| Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 3 (Registration Reply)
A bit (New) Replaces high order bit in RFC-2002
Code field.
If A bit = 0, then this is a Traditional
RFC 2002 Registration Reply extension.
If A bit = 1, then this is a modified
registration reply and is followed by a
Network Access Identifier extension,
Authentication extension and Certificate
extension.
Code A value indicating the result of the Registration
Request. Currently defined Code values are shown
In Table 2.3 below.(redefined from 8 bits in
RFC-2002 to now 7 bits)
Lifetime Unchanged from base Mobile IP protocol.
Home Address Unchanged from base Mobile IP protocol.
Home Agent Unchanged from base Mobile IP protocol.
Care-of Address Unchanged from base Mobile IP protocol.
Identification Unchanged from base Mobile IP protocol.
Jacobs, Belgard [Page 12]
INTERNET DRAFT 09 July 2001
Extensions When A bit = 0,Usage is as follows between Home
Agent and Foreign Agent
- RFC 2002 formatted Home Agent Authentication
extension is appended.
When A bit = 0,Usage is as follows between
Foreign Agent and Mobile Node
- RFC 2002 formatted Home Agent Authentication
extension is appended.
- RFC 2002 formatted Foreign Agent
Authentication extension is appended.
When A bit = 1, Usage is as follows between Home
Agent and Foreign Agent
- Home Agent Network Access Identifier
extension is appended.
- Modified Home Agent Authentication extension
is appended.
- Home Agent Certificate extension is appended.
When A bit = 1,Usage is as follows between
Foreign Agent and Mobile Node
- Home Agent Network Access Identifier
extension is appended.
- Modified Home Agent Authentication extension
is appended.
- Foreign Agent Network Access Identifier
extension is appended.
- Foreign Agent Authentication extension is
appended.
Table 2.3 -- Currently defined Code values are
0 = Unchanged from base Mobile IP protocol.
1 = Unchanged from base Mobile IP protocol.
64 = Unchanged from base Mobile IP protocol.
65 = Unchanged from base Mobile IP protocol.
66 = Unchanged from base Mobile IP protocol.
67 = Unchanged from base Mobile IP protocol.
68 = Unchanged from base Mobile IP protocol.
69 = Unchanged from base Mobile IP protocol.
70 = Unchanged from base Mobile IP protocol.
71 = Unchanged from base Mobile IP protocol.
72 = Unchanged from base Mobile IP protocol.
73 = Unchanged from base Mobile IP protocol.
80 = Unchanged from base Mobile IP protocol.
81 = Unchanged from base Mobile IP protocol.
82 = Unchanged from base Mobile IP protocol.
88 = Unchanged from base Mobile IP protocol.
89 = foreign agent failed authentication
Jacobs, Belgard [Page 13]
INTERNET DRAFT 09 July 2001
4.1.4. Mobile IP Authentication Extensions
The extended Mobile IP uses Authentication extensions appended to
Agent Advertisements, Registration Requests and Registration Reply
messages to provide receiving nodes the information to verify the
authenticity and integrity of received Mobile IP control messages.
The digital signature computed for each authentication Extension MUST
protect the following fields from the registration message:
- the UDP payload (that is, the Registration Request or
Registration Reply data),
- all prior Extensions in their entirety, and
- the Type and Length of this Extension.
Note that the digital signature field itself and the UDP header are
NOT included in the computation of the digital signature value.
Table 2.4 -- Valid Authentication types, when A bit = 1.
Auth Type | Authentication | Key Length | Digital Signature
Value | Algorithm | in bits | Length in bytes
-----------|----------------|--------------|------------------
001 to 009 | User Defined | User Defined | User Defined
011 | RSA | 512 | 64
012 | RSA | 768 | 97
013 | RSA | 1024 | 128
014 | RSA | 2048 | 256
021 | Elliptic Curve | 80 | 10
022 | Elliptic Curve | 120 | 15
023 | Elliptic Curve | 160 | 20
030 | DSA | 512 | 64
Jacobs, Belgard [Page 14]
INTERNET DRAFT 09 July 2001
4.1.4.1. Mobile Node Authentication Extension
Exactly one Mobile Node Authentication Extension MUST be appended to
all Registration Requests. The format of the Mobile Node
Authentication Extension is:
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 | Auth Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node (MN) Digital Signature |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 32 (Mobile Node Authentication Extension)
Length 4 plus the number of bytes in the digital signature
Auth Type When the A bit is set, the Auth Type identifies the
public key cryptographic method (algorithm) and key
Length used to generate digital signatures. Valid
Authentication types are shown in Table 2.4.
Mobile Node The computed MN Private key based Digital Signature.
Digital
Signature
Jacobs, Belgard [Page 15]
INTERNET DRAFT 09 July 2001
4.1.4.2. Foreign Agent Authentication Extension
Exactly one Foreign Agent Authentication Extension must be appended to
all Registration Requests being passed from an FA to an HA or
Registration Replies sent from an FA to a MN. The format of the
Foreign Agent Authentication Extension is:
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 | Auth Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Foreign Agent (FA) Digital Signature |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 33 (Foreign Agent Authentication Extension)
Length 4 plus the number of bytes in the digital signature
Auth Type When the A bit is set, the Auth Type identifies the
public key cryptographic method (algorithm) and key
Length used to generate digital signatures. Valid
Authentication types are shown in Table 2.4.
Foreign The computed FA Private key based Digital Signature.
Agent
Digital
Signature
Jacobs, Belgard [Page 16]
INTERNET DRAFT 09 July 2001
4.1.4.3. Home Agent Authentication Extension
Exactly one Home Agent Authentication Extension must be appended to
all Registration Replies being sent from an HA to an MN. The format of
the Home Agent Authentication Extension is:
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 | Auth Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digital Signature |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 34 (Home Agent Authentication Extension)
Length 4 plus the number of bytes in the digital signature
Auth Type When the A bit is set, the Auth Type identifies the
public key cryptographic method (algorithm) and key
Length used to generate digital signatures. Valid
Authentication types are shown in Table 2.4.
Home Agent The computed HA Private key based Digital Signature.
Digital
Signature
Jacobs, Belgard [Page 17]
INTERNET DRAFT 09 July 2001
4.1.4.4. Network Access Identification extension
A Network Access Identification extension must preceed an
Authentication extension. The format of the Network Access
Identification extension is:
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 | NAI Length |Network Access Identifier (NAI)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Access Identifier (NAI)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CA-NAI Length | CA-Network Access Identifier (CA-NAI)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CA-Network Access Identifier (NAI) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 11 (Network Access Identification extension)
Network Length in bytes of the Network Access Identifier
Access
Identifier
Length
Network The Network Access Identifier (NAI) is an ASCII text
Access string of up to XXXX bytes of an arbitrary format and
Identifier length that uniquely identifies the network node. The
NAI MUST match the subject identifier contained in an
X.509 digital certificate for this network node.
CA Network Length in bytes of the CA Network Access Identifier
Access
Identifier
Length
CA Network The Certificate Authority (CA) Network Access
Access Identifier (CA-NAI) is an ASCII text string of up to
Identifier XXXX bytes of an arbitrary format and length that
uniquely identifies a certificate Authority. The
CA-NAI MUST match the signing CA identifier
contained in the X.509 digital certificate for this
network node.
Jacobs, Belgard [Page 18]
INTERNET DRAFT 09 July 2001
4.1.4.5 Certificate Extension
The Certificate Extension is used to transfer authentication
information (Certificates) between MNs, FAs and HAs. The fields of
the Certificate Extension are:
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 | Ext-Length | Cert-cnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender-Certificate-Length | Sender-Certificate
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender-Certificate, continued . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional CA-Certificate-Length| Optional CA-Certificate
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CA-Certificate, continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| additional <CA_CERT>s as necessary . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 10 Identifies this as a Certificate Extension.
Ext Length: The length of the Certificate Extension in bytes.
set to 6 + value of Sender-Certificate-Length field
The value is increased again for each additional
certificate in the Extension by 2 plus the value
found in each additional CA-Certificate-Length
Field.
Sender-Certificate-Length: Length in bytes of the X.509 Type 3
formatted Certificate of the message
sender.
Sender-Certificate: The X.509 Type 3 Formatted Certificate of
the message sender which contains the public
key of the message sender.
CA-Certificate-Length: Length in bytes of the X.509 Type 3
formatted certificate of a Certificate
Authority (CA). This field MUST be present
if authentication relies on public keys
and Certificate Authorities.
CA-Certificate: The X.509 Type 3 formatted certificate of a CA
which contains the public key of the CA used to
sign Certificates. This field MUST be present if
authentication relies on public keys and
Certificate Authorities.
Jacobs, Belgard [Page 19]
INTERNET DRAFT 09 July 2001
5. Protocol Overview
For this extended Mobile IP, a complete registration cycle consists of:
a) the MN receiving a Mobility Agent Advertisement
b) the MN sending a Registration Request to the FA
c) the FA preprocessing the received Registration Request and, if
tentatively approved, passing the Registration Request to the
MN's HA
d) the HA receiving the Registration from the MN, via the FA
e) the HA processing the Registration Request and sending a
Registration Reply to the FA
f) the FA receiving the Registration Reply, updating visiting MN
data structures
g) the FA sending the completed Registration Reply to the visiting
MN.
Proposed authentication changes apply to the messages associated with
both the Agent Discovery and the Registration procedures..
When secret key based authentication is being used then MNs, FAs and
HAs follow the procedures specified in RFC-2002. The Following
sections (3.1 through 3.12) describe Mobile IP authentication based
upon public keys.
5.1. Agent Discovery with Public key Authentication
FAs advertise their presence via a Mobility Agent Advertisement
Extension appended to ICMP Router Advertisements generated by
Mobility Agents acting as Foreign Agents. The visiting MN obtains a
Care-OF-Address (COA) from these Mobility Agent Advertisement
Extensions (Agent Advertisements).
Our extended Agent Advertisement has appended to it:
- a Foreign Agent Network Access Identifier (NAI) Extension appended which
contains the NAI of the FA and the NAI of a Certificate Authority that has
signed an X.509 digital certificate for this FA.
- a Foreign Agent Authentication Extension containing a digital signature
that is used to authenticate the contents of the Agent Advertisement
message.
- a Certificate Extension so that MNs can quickly obtain a authentic copy of
the FA's public key.
The specific authentication related steps the FA follows are:
1. The FA creates the Agent Advertisement, as per RFC-2002, and sets the new
A bit to "1"
2. The FA creates the Agent NAI Extension and appends it to the
Advertisement
3. The FA uses it's private key to produce a digital signature
spanning all Agent Advertisement fields and NAI extension fields and
places this digital signature in a Foreign Agent Authentication
Extension.
4. The FA creates a Certificate Extension placing a copy of its
Certificate, and any Certificates belonging to CAs necessary for
Jacobs, Belgard [Page 20]
INTERNET DRAFT 09 July 2001
trust hierarchy creation, into the Certificate Extension.
5. The FA appends the Foreign Agent Authentication Extension and the
Certificate Extension to the Agent Advertisement, plus NAI extension,
message.
The FA follows RFC-2002 regarding the transmission of Agent
Advertisement messages.
5.2. MN Processing of Agent Advertisements with Public key
Authentication
When the MN receives an Agent Advertisement, the MN follows the base
Mobile IP protocol except for the following authentication actions:
1. The MN extracts the Certificates necessary for trust hierarchy
creation from the Certificate Extension and, in the case where the
FA and the MN share the same CA, the MN uses the CA's public key
to validate the FA's Certificate.
2. In the case where the MN and the FA do not share a common CA, the
MN uses any other CA Certificates contained in the Certificate
Extension to establish a trust hierarchy path between the MN's CA
and the FA's CA
3. In the case where the MN is unable to establish a trust hierarchy
path between the CAs, the MN ceases further authentication
processing and considers the Agent Advertisement message not
authentic, the sending FA as not a valid candidate to register
with and the MN ignores this Agent Advertisement message.
4. Should the MN be able to establish a trust hierarchy path between
CAs, the MN proceeds down the path verifying CA Certificates
stopping when the Certificate of the advertising FA has been
verified.
5. Upon verification of the FA's Certificate, the MN uses the FA's
public key from the FA Certificate to verify the digital signature
in the Foreign Agent Authentication Extension, created using the
FA's private key.
6. Upon successful verification of the Foreign Agent Authentication
Extension digital signature, the MN continues with normal
processing of the Agent Advertisement message as specified in the
base Mobile IP protocol.
Should the Agent Advertisement digital signature not pass
verification, the MN ceases further processing and considers the Agent
Advertisement message as not authentic, the sending FA as not a valid
candidate to register with and the MN ignores this Foreign Agent
Advertisement message.
5.3. MN Registration Request Generation
When the MN generates a Registration Request message, the MN follows
the base Mobile IP protocol except for the following authentication
actions:
1. The MN sets the new A bit, in the Registration Request to "1".
2. The MN creates the MN NAI Extension and appends it to the Registration
Request
Jacobs, Belgard [Page 21]
INTERNET DRAFT 09 July 2001
3. The MN uses it's private key to produce a digital signature
spanning all Registration Request fields and NAI extension fields and
places this digital signature in a Mobile Node Authentication Extension.
4. The MN then creates a Certificate Extension placing a copy of
its Certificate, and any Certificates belonging to CAs necessary
for trust hierarchy creation, into the Certificate Extension.
5. The MN appends the Certificate Extension to the end of the
Registration Request message following the Mobile Node
Authentication Extension.
The MN continues with the actions specified in RFC-2002 for sending out
Registrations Requests.
5.4. Registration Request Processing by FA
When the FA receives a Registration Request from an MN, the FA follows
the base Mobile IP protocol except for the following authentication
actions:
1. The FA extracts the Certificates from the Certificate Extension
and, in the case where the FA and the MN share the same CA, the
FA uses the CA's public key to validate the MN's Certificate.
2. In the case where the MN and the FA do not share a common CA,
then the FA uses any other CA Certificates contained in the
Certificate Extension to establish a trust hierarchy path
between the FA's CA and the MN's CA.
3. In the case where the FA is unable to establish a trust hierarchy path
between the CAs, the FA ceases further authentication processing and
considers the Registration Request message not authentic, the sending
MN as not allowed to attach to the FA's network, the FA logs the
authentication failure and creates a Registration Reply message informing
the MN that the MN's Registration Request is not allowed having failed
authentication.
4. Should the FA be able to establish a trust hierarchy path between
CAs. The FA proceeds down the path verifying CA Certificates
stopping when the Certificate of the MN has been verified.
5. The FA uses the MN's public key from the MN Certificate to verify
the digital signature in the Mobile Node Authentication
Extension, created using the MN's private key.
6. Upon successful verification of the Mobile Node Authentication
Extension digital signature, the FA continues with normal
processing of the Registration Request message as specified in the
base Mobile IP protocol except for authentication actions.
7. Should the Mobile Node Authentication Extension digital signature
not pass verification, the FA ceases further authentication
processing and considers the Registration Request message not
authentic, the sending MN as not allowed to attach to the FA's
network, the FA logs the authentication failure and creates a
Registration Reply message informing the MN that the MN's
Registration Request is not allowed having failed authentication.
Jacobs, Belgard [Page 22]
INTERNET DRAFT 09 July 2001
5.5. FA Forwarding Registration Requests to HA
When the FA finishes basic Registration Request processing and is
preparing to forward the Registration Request to the MN's Home Agent
(HA), the FA performs the following authentication actions:
1. The FA deletes the received Certificate Extension.
2. The FA creates the Foreign Agent NAI Extension and appends it to the
Advertisement
3. The FA uses it's private key to produce a digital signature
spanning all Registration Request fields and NAI extension fields and
places this digital signature in a Foreign Agent Authentication
Extension.
2. The FA uses it's private key to produce a digital signature
spanning all Registration Request message fields and places the
digital signature in a Foreign Agent Authentication Extension
appended following the NAI extension.
3. The FA places a copy of its Certificate, and copies of any other
Certificates necessary for establishing a trust hierarchy, into a
new Certificate Extension.
4. The FA appends the Certificate Extension to the end of the
Registration Request message following the Foreign Agent
Authentication Extension.
5. The FA continues with the actions specified in RFC-2002 for
sending out Registrations Requests.
5.6. Registration Request Authentication verification by HA
When the HA receives a Registration Request forwarded from an FA, the
HA follows the base Mobile IP protocol except for the following
authentication actions:
1. The HA extracts the Certificates from the Certificate Extension
and, in the case where the FA and the HA share the same CA, the HA
uses the CA's public key to validate the FA's Certificate.
2. In the case where the HA and the FA do not share a common CA, then
the HA uses any other CA Certificates contained in the Certificate
Extension to establish a trust hierarchy path between the HA's CA
and the FA's CA.
3. In the case where the HA is unable to establish a trust hierarchy
path between the CAs, the HA ceases further authentication
processing and considers the Registration Request message invalid,
the forwarding FA as untrustworthy as a Foreign Agent, the HA logs
the authentication failure and creates a Registration Reply
message informing the FA that the MN's Registration Request is not
allowed having failed FA authentication.
4. Should the HA be able to establish a trust hierarchy path between
CAs. The HA proceeds down the path verifying CA Certificates
stopping when the Certificate of the FA has been verified.
5. The HA uses the FA's public key from the FA Certificate to verify
the FA digital signature in the Foreign Agent Authentication
Extension, created using the FA's private key.
Jacobs, Belgard [Page 23]
INTERNET DRAFT 09 July 2001
6. The HA uses the MN's public key, from the MN Certificate that the
HA already possesses, to verify the MN digital signature in the
Mobile Node Authentication Extension, created using the MN's
private key.
7. Upon successful verification of the Registration Request message
digital signatures, the HA continues with normal processing of the
Registration Request message as specified in the base Mobile IP
protocol except for authentication actions.
8. Should the Registration Request message digital signatures not
pass verification, the HA ceases further authentication processing
and considers the Registration Request message not authentic, the
requested registration as prohibited, the HA logs the
authentication failure and creates a Registration Reply message
informing the FA and the MN that the MN's Registration Request is
not allowed having failed authentication.
5.7. HA Generation of Registration Reply
When the HA generates a Registration Reply message, the HA follows the
base Mobile IP protocol except for the following authentication
actions:
1. The FA sets the new A bit to "1".
2. The FA creates the Agent NAI Extension and appends it to the Registration
Reply message.
3. The HA uses it's private key to produce a digital signature
spanning all Registration Reply fields and NAI extension fields and
places this digital signature in a Home Agent Authentication Extension
which it appends to the Registration Reply.
2. The HA then creates a Certificate Extension placing a copy of its
Certificate into the Certificate Extension.
3. The HA appends the Certificate Extension to the end of the
Registration Request message following the Home Agent
Authentication Extension.
4. The HA continues with the actions specified in RFC-2002 for sending
out Registrations Requests.
5.7.2. HA Generation of Registration Reply With DHCP Involved
When the HA generates a Registration Reply message, the HA follows
RFC-2002 except for the following authentication actions:
1. The HA uses it's private key to produce a digital signature
spanning all Registration Request message fields and places the
digital signature in an Home Agent Authentication Extension which
it appends to the Registration Reply.
2. The HA continues with the actions specified in RFC-2002 for
sending out Registrations Requests.
Jacobs, Belgard [Page 24]
INTERNET DRAFT 09 July 2001
5.8. Registration Reply Authentication verification by FA
When the FA receives a Registration Reply from an HA, the FA follows
the base Mobile IP protocol except for the following authentication
actions:
1. The FA extracts the HA's Certificate from the Certificate
Extension and uses the public key from the Certificate of the HA's
CA to validate the HA's Certificate.
2. The FA uses the HA's public key from the HA Certificate to verify
the digital signature in the Home Agent Authentication Extension,
created using the HA's private key.
3. Upon successful verification of the Home Agent Authentication
Extension digital signature, the FA continues with normal
processing of the Registration Reply message as specified in the
base Mobile IP protocol except for authentication actions.
4. Should the Registration Reply message digital signature not pass
verification, the FA ceases further authentication processing and
considers the Registration Reply message not authentic, the
sending HA as not a valid HA, the FA logs the authentication
failure and creates a Registration Reply message informing the MN
that the MN's Registration Request is not allowed having failed
authentication.
5.9. FA Forwarding Registration Reply to MN
When the FA finishes basic Registration Reply processing and is
preparing to forward the Registration Reply to the MN, the FA performs
the following authentication actions:
1. The FA deletes the Certificate Extension received from the HA.
2. The FA uses it's private key to produce a digital signature
spanning all Registration Reply message fields and places the
digital signature in a Foreign Agent Authentication Extension
following the Home Agent Authentication Extension.
3. The FA continues with the actions specified in RFC-2002 for
sending out Registrations Replies.
5.10. MN Receipt of Registration Reply
When the MN receives a Registration Reply forwarded from an FA, the
MN follows the base Mobile IP protocol except for the following
authentication actions:
1. The MN uses the FA's public key from the FA Certificate, that
the MN already possesses, to verify the FA digital signature in
the Foreign Agent Authentication Extension, created using the
FA's private key.
2. The MN uses the HA's public key, from the HA Certificate, that
the MN already possesses, to verify the HA digital signature in
the Home Agent Authentication Extension, created using the HA's
private key.
3. Upon successful verification of the Registration Reply message
digital signatures, the MN continues with normal processing of the
Jacobs, Belgard [Page 25]
INTERNET DRAFT 09 July 2001
Registration Reply message as specified in the base Mobile IP
protocol except for authentication actions.
4. Should the Registration Reply message digital signatures not pass
verification, the MN ceases further authentication processing and
considers the Registration Reply message not authentic, the MN
logs the authentication failure and restarts its efforts to find a
foreign network the MN can register with.
5.11. FA Generation of Registration Reply
When the FA generates a Registration Reply message rejecting an MN's
request to register with the FA's network, the FA follows the base
Mobile IP protocol except for the following authentication actions:
1. The FA uses it's private key to produce a digital signature
spanning all Registration Rely message fields and places the
digital signature into a Foreign Agent Authentication Extension
appended to the Registration Reply.
2. The FA continues with the actions specified in RFC-2002 for
sending out Registrations Replies.
5.12. MN Receipt of Registration Reply
When the MN receives a Registration Reply generated by an FA, the MN
follows the base Mobile IP protocol except for the following
authentication actions:
1. The MN uses the FA's public key from the FA Certificate, which the
MN already possesses, to verify the FA digital signature in the
Foreign Agent Authentication Extension, created using the FA's
private key.
2. Upon successful verification of the Registration Reply message FA
digital signature, the MN continues with normal processing of the
Registration Reply message as specified in the base Mobile IP
protocol except for authentication actions.
3. Should the Registration Reply message FA digital signature not
pass verification, the MN ceases further authentication processing
and considers the Registration Reply message not authentic, the MN
logs the authentication failure and restarts its efforts to find a
foreign network the MN can register with.
6. Certificates
This extended Mobile IP provides for two forms of certificates:
1) certificates signed by Certificate Authorities and issued on behalf
of the certificate subject by the Certificate Authority and
2) certificates signed by the subject of the certificate and issued by
the subject.
6.1. Certificate Authority Signed Certificates
Certificate Authority Signed Certificates MUST include the following fields:
Jacobs, Belgard [Page 26]
INTERNET DRAFT 09 July 2001
Distinguished Name - The Distinguished Name (DN) is the Network Access
Identifier (NAI). The use of this field is a
variation of the DN approach defined in [X.500].
Not Valid Before Date - Not Valid Before Date (NVBD) is that date
prior to which the Certificate is not
valid
Not Valid After Date - Not Valid After Date (NVAD) is that date
After which the Certificate is not valid
CA Distinguished Name - The CA Distinguished Name (DN) is the Network
Access Identifier (NAI) assigned to this CA.
Subject Public Key - Subject Public Key is the binary string of
Octets containing the public key of the
sender
Public Key Algorithm - Public Key Algorithm is the field that
Identifies the type of public key algorithm
the sender's public key must be used with
Public Key Size - Public Key Size is the field that identifies
the size of the sender's public key in octets
CA Digital Signature - CA Digital Signature is the digital
Signature generated by the sender's CA that
binds the other fields of the Certificate
together cryptocraphicly
Certificate Serial Number - A unique number assigned to a
Certificate by the CA that creates and
digitally signs the Certificate. This
serial number is used to positively
identify the Certificate
6.2 Self-Signed Certificates
With self-signed certificates each node acts as its own CA by creating
a certificate for itself containing a public key that the node
"certifies" as it's public key. This form of public key authentication
is typically called an informal web of trust similar to that used with
Pretty Good Privacy (PGP) public keys. Self-signed Certificates used
with SSA Mobile IP MUST include the same fields as Certificate
Authority Signed Certificates except for the following:
Signer Distinguished Name - This field replaces the CA
Distinguished Name field and contains
Jacobs, Belgard [Page 27]
INTERNET DRAFT 09 July 2001
the Network Access Identifier (NAI) of the
node which created the certificate.
Signer Digital Signature - This field replace the CA Digital
Signature field and contains the digital
Signature, generated by the certificate
creator, that binds the other fields of
the Certificate together
cryptocraphicly.
Certificate Serial Number - A unique number assigned to a
Certificate by the node that creates
and digitally signs the Certificate.
This serial number is used to
positively identify the Certificate
7. Trust Hierarchy Paths
A Trust Hierarchy Path is the establishment of a logical chain
between two Certificate Authorities (CAs) and reflects a trust
relationship that can be established through intervening CAs.
Validation of a Certificate involves constructing a Trust Hierarchy
Path between the sender Certificate, the CA that issued the sender
Certificate and the CA of the validating system. The validity
interval for every Certificate in this path must be checked.
Establishing a trust hierarchy path MUST be performed to verify the
authenticity and usability of Certificates within Mobile IP.
This process assumes that the receiver knows the public key of the
Sender's CA. The receiver can develop trust in the public key of the
Sender's CA recursively, if the receiver has a Certificate containing
the CA's public key signed by a superior CA whom the receiver already
trusts. In this sense, a certificate is a stepping stone in digital
trust. Each certificate is processed in turn, starting with that
signed using the input trusted public key.
The following checks are applied to all Certificates:
- Check that the signature verifies
- That dates are valid
- The subject and issuer names chain correctly
- The certificate has not been revoked.
If any of the above checks fails, the procedure terminates, returning
a failure indication. If none of the above checks fail on each
Certificate, the procedure terminates successfully.
8. Certificate Revocation Lists
Each CA signed digital certificate should be checked against the
current Certificate Revocation List (CRL) from the issuing CA to
ensure that revoked Certificate are not employed. SSA Mobile IP
Jacobs, Belgard [Page 28]
INTERNET DRAFT 09 July 2001
recognizes that network performance could be seriously degraded if
a receiving node always retrieves the most recent CRL when ever a
new CA Signed Certificate is received. Consequently, a node (be it
an MN, FA or HA) should cache received CA signed Certificates along
with a value ("staleness value") that indicates the last time each
Certificate was checked against a CRL from the issuing CA. The node
should also provide a value that indicates the maximum degree
("staleness threshold") of Certificate staleness a given node may
tolerate before the node has to retrieve the appropriate CRL and
verify that the Certificate has not been revoked.
This staleness checking function is a compromise between the effect
on available bandwidth vs. the risk of using a revoked Certificate.
In those cases where the node has high network bandwidth available
(usually FAs and HAs), via wired network attachments, then the
staleness threshold should be set to a relatively low value (eg. 10
seconds). Where the node has less than good network bandwidth
available (usually MNs) via wireless network attachments then the
staleness threshold should be set to a higher value (eg. 10 minutes).
9. Security Considerations
Use of Mobile IP without authentication between the MN and the FA,
such as with DHCP, do not provide for visited network access control
and accounting. Likewise the MN has no basis to trust the visited
network not to miss-direct or copy MN sourced packets.
Mobile IP relies on the use of the Address Resolution Protocol (ARP)
for intercepting packets destined for a traveling MN. Unfortunately
ARP does not include authentication mechanisms. Any wireless home
network is consequently vulnerable to MN traffic stealing by having
a hostile node on the wireless network issue ARP messages which cause
these packets to be sent to a destination other than an MN, when at
home, or the MN's HA when the MN is on the road. Ideally the ARP
protocol should include authentication but this would require
significant changes to the currently deployed protocol.
Staleness of Certificates and frequency for Certification Revocation
List retrieval is a trade-off between exposure and potential
threat resulting in a degree of risk from a revoked Certificate. By
having implementations of SSA Mobile IP provide a user tunable
staleness threshold the degree of risk becomes a user managed
function.
Patent Issues
There are no patent issues at this time. The MIT patent (#4405829) governing
the RSA cryptography algorithm expired on December 15, 1999 and no longer
applies.
Jacobs, Belgard [Page 29]
INTERNET DRAFT 09 July 2001
References
[Diffie76] Diffie, W., Hellman, M. E., "New directions in
cryptography", IEEE Transactions on Information Theory,
IT-22(6):644--654, November 1976.
[NIST94] National Institute of Standards and Technology,
NIST FIPS PUB 186, "Digital Signature Standard",
US. Department of Commerce, May 1994
[RFC1319] Kaliski, B., "The MD2 Message-Digest Algorithm",
April 1992.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", April 1992.
[RFC1422] Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management",
February 1993
[RFC1541] Droms, R., "Dynamic Host Configuration Protocol",
October 1993
[RFC2002] Perkins, C., editor, "IP mobility support", October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", March 1997.
[RFC2486] Aboba, B., Beadles, M., "The Network Access Identifier",
January 1999
[RSA78] Rivest, R.L., Shamir, A., Adleman, L., "A method for
obtaining digital signatures and public-key cryptosystems",
Communications of the ACM, 21(2):120-126, February 1978.
[Schneier96] Schneier, B., "Applied Cryptography 2nd Edition",
Chapter 22 pp. 513-514, John Wiley & Sons Inc., 1996
[X.500] "CCITT. Recommendation X.500: The Directory-Overview of
Concepts, Models and Services", 1988
[X.509] "CCITT. Recommendation X.509: The Directory-Authentication
Framework", 1988.
Jacobs, Belgard [Page 30]
INTERNET DRAFT 09 July 2001
Authors' Address
Questions about this memo can also be directed to:
Stuart Jacobs
Network Security Group
Verizon Laboratories,
40 Sylvan Road,
Waltham, MA 02451-1128, USA.
Phone: 781-466-3076
Fax: 781-466-2838
Email: Stu.Jacobs@Verizon.com
Scott Belgard
Network Security Group
Verizon Laboratories,
40 Sylvan Road,
Waltham, MA 02451-1128, USA.
Phone: 781-466-2826
Fax: 781-466-2838
Email: Scott.Belgard@Verizon.com
Jacobs, Belgard Expires July 1999 [Page 31]