Internet Engineering Task Force S. Jacobs
INTERNET DRAFT GTE Laboratories
August 1, 1998
Mobile IP Public Key Based Authentication
draft-jacobs-mobileip-pki-auth-00.txt
Status of This Memo
This document is a submission to the Mobile-IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the mobile-ip@smallworks.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. 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 made obsolete 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document proposes an extension to the Mobile IP base protocol.
The purpose of this extension is 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. The use of these
mechanisms will allow Mobile IP to scale to tens of thousands of
mobile nodes across networks owned-operated by different
organizations and service providers.
Expires March 1, 1999 [Page i]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
Contents
Abstract ........................................................... i
1. Introduction................................................. 1
1.1. Mobility Security Requirements .............................. 1
1.2. Security Deficiencies of Mobile IP .......................... 3
1.3. Trusted Third Party needed .................................. 5
1.4. Terminology ................................................. 5
1.5. Security Enhancement ........................................ 7
2. Protocol Overview ........................................... 7
2.1 Agent Discovery ............................................. 8
2.2 MN Processing of Agent Advertisements ....................... 9
2.3 MN Registration Request Generation .......................... 9
2.4 Registration Request Authentication verification by FA ...... 10
2.5 FA Forwarding Registration Requests to HA ................... 10
2.6 Registration Request Authentication verification by HA ...... 11
2.7 HA Generation of Registration Reply ......................... 12
2.8 Registration Reply Authentication verification by FA ........ 12
2.9 FA Forwarding Registration Reply to MN ...................... 12
2.10 MN Receipt of Registration Reply forwarded by FA ............ 13
2.11 FA Generation of Registration Reply ......................... 13
2.12 MN Receipt of Registration Reply Generated by FA ............ 14
3. Message and Extension Formats ............................... 14
3.1 Certificate Extension ....................................... 14
3.2. Mobility Agent Advertisement Extension ...................... 15
3.3. Registration Request Message ................................ 16
3.4. Registration Reply .......................................... 18
3.5. Mobile IP Authentication Extensions ......................... 19
3.5.1. Computing Authentication Extension Values ................... 19
3.5.2. Mobile Authentication Extension ............................. 19
3.5.3. Foreign Authentication Extension ............................ 20
3.5.4. Home Authentication Extension ............................... 21
3.5.5 Correct Sequence of Extension ............................... 21
4. Certificates ................................................ 23
5. Trust Hierarchy Paths ....................................... 24
6. Certificate Revocation Lists ................................ 24
7. Security Considerations ..................................... 26
A. Patent Issues ............................................... 26
References ......................................................... 27
Authors' Address ................................................... 27
Expires March 1, 1999 [Page ii]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
1. Introduction
The Mobile IP base protocol [RFC2002] provides an efficient, scalable
mechanism for node mobility within the Internet. However, so long as
the authentication of Mobile IP control messages rely on the use of
secret key mechanisms, then key management remains a major hindrance
to large scale deployment of Mobile IP.
1.1. Mobility Security Requirements
As the use of mobile nodes becomes more common, five security related
requirements become vital:
- Authentication. The receiver of a message must be able to
ascertain who the actual originator of the message is; thereby
preventing an intruder from masquerading as a legitimate source of
the message in question.
- Authorization. The organization which owns/operates a network
must have the ability to decide who may attach to the network
and what network resources may be used by the attaching (visiting)
node.
- Integrity. The receiver of a message must be able to ascertain
whether a message has been modified in transit; thereby preventing
an intruder from altering messages.
- Nonrepudiation. The sender of a message must not be able to
falsely deny that it originated a message at a later time.
- Key Management. The only method available to accurately enforce
authentication, integrity and nonrepudiation is by using some form
of cryptography; which requires the distribution/exchange of
encryption key information amongst message senders and receivers.
Expanding on these points:
AUTHENTICATION
Authentication may be provided in many forms with varying degrees of
assurance; from simple passwords transmitted in the clear to digital
signatures based on either secret or public key cryptographic
algorithms. The majority of networks mobile nodes visit will be
wireless nets which are subject to eavesdropping and unable to
control actual attachment via physical controls. Unless a commercial
or military wireless network provides encryption, frequency hopping
or other form of link layer access controls or privacy mechanisms, a
rogue or hostile Foreign Agent (FA) could transmit messages
indistinguishable from legitimate FA messages.
When a Mobile Node (MN) receives an Agent Advertisement message, the
MN needs to know that the advertisement comes from a valid FA on the
network the MN wants to register with. In those cases where no
authentication process between a FA and an MN occurs, or the
authentication process used is computationally easy to negate, a
hostile FA could easily masquerade as a legitimate FA and present a
denial-of-service threat by:
Expires March 1, 1999 [Page 1]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
- issuing Registration Reply messages stating the MN registration
request is denied
- forwarding MN Registration Requests to an address other than that
of the MN's Home Agent (HA) causing the MN to never receive a
Registration Reply from it's HA, or
- discarding MN Registration Requests causing the MN to never
receive a Registration Reply from it's HA.
When a MN wants to attach to a foreign network, the FA needs to know
the authentic identity of the MN so the FA can determine whether to
allow the MN it's requested attachment. The actual decision to allow
the attachment falls within the area of authorization but the FA
cannot make a valid decision unless it knows, with some defined
degree of assurance, that the MN is who it says it is.
It becomes readily apparent that authentication plays a key role in
IP mobility in avoiding denial-of-service risks and as the
foundation for access control decisions.
AUTHORIZATION
Access control (authorization) at a foreign network being visited by
an MN is critical within a mobile node context. Networks supporting
visiting MNs need the ability to decide which MNs are allowed
visiting rights. These networks also need a mechanism by which
access control information may be defined, stored, validated and
applied to requested MN visits. An IP mobility protocol needs to
address the mechanism(s) by which a network node obtains
authorization information and guidelines to ensure interoperability
between different implementations.
INTEGRITY
Any messages sent between MNs, HAs and FAs that affect how IP packets
are routed must be received at the destination exactly as sent by the
message source. Failure to validate the integrity of these types of
messages allows a hostile node to modify these messages while in
transit. Modification could easily result in an MN's attempt to
register at a foreign network being denied or the registration
occurring but packets destined for the MN, at the foreign network,
being miss-routed/lost.
NONREPUDIATION
When a MN visits a foreign network the MN will consume network
resources (i.e., number of packets sent/received, number of packets
detunneled by the FA, assigned IP address space, etc.). From the
perspective of the organization responsible for the visited network,
a record of what resources are consumed by the visiting MN needs to
be kept for performance and accounting management purposes. Should
the organization want to charge/bill for the use of these resources,
then the FA must have a way of identifying which MN consumed what
resources such that the owner of the MN cannot deny the visit or
Expires March 1, 1999 [Page 2]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
resources consumed.
KEY MANAGEMENT
Industrial strength authentication, integrity and nonrepudiation
approaches are based primarily on the use of cryptographic
algorithms. Modern cryptographic algorithms base their security
capabilities on the use of a key, or keys, which allows the
algorithm(s) to be publicly available so long as the keying
information is kept and distributed in a private (i.e., secure)
manner.
One method for distributing the key information is to manually load
it into each node. This is fine for a small number of nodes but runs
into administrative problems. Page 29 of [Schneier96] highlights
this problem by noting that if a separate key is used by each pair of
nodes for authentication purposes, the total number of keys increases
rapidly as the number of users increases. N users requires N(N-1)/2
keys. Authentication amongst 100 nodes would require 4950 key pairs
and amongst a 1000 nodes would require 499,500 keys, where each key
must be kept private and distributed in a secure manner. It quickly
becomes apparent that a manual key distribution approach is not
feasible for use in IP mobility authentication except with a very
small number of nodes.
A truly viable solution for Mobile Nodes must scale well to large
numbers of mobile nodes by providing a secure dynamic key
distribution function.
1.2 Security Deficiencies of Mobile IP
As already noted strong authentication is the corner-stone upon which
access control, integrity, and non-repudiation rely. Mobile IP
currently only requires that registration messages between an MN and
its HA be authenticated. Registration messages between an HA and an
FA, or between an MN and an FA, may be optionally authenticated.
The majority of networks MNs visit will be wireless nets which are
subject to eavesdropping and unable to control actual attachment via
physical controls. Unless authentication between FAs and HAs and
between FAs and MNs is mandatory, Mobile IP will never succeed
commercially.
A number of alternative approaches are under consideration for
Mobile IP authentication, and associated key management/distribution.
Although not part of any RFC at this time, these approaches are
considered here.
THE HA AS A KEY DISTRIBUTION CENTER (KDC)
The approach of using the HA as a KDC, requires:
- the HA have a secret key based security association with the MN
- the HA have a secret key based security association with the FA
Expires March 1, 1999 [Page 3]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
- the HA to generate, encrypt and distribute Registration keys for
use by the FA and MN.
This approach requires the use of three separate secret keys for one
MN to register with one FA. When scaled to large networks we are
facing the need for thousands of secret keys, two thirds of which are
manually distributed and one third generated, encrypted and
distributed dynamically as MNs register on foreign networks. An HA,
supporting 20 MNs who roam to new foreign networks every 5 minutes,
is faced with having to generate, encrypt and distribute as many as
120 secret keys per hour (30 seconds for each new key). An HA,
supporting 100 MNs who roam to new foreign networks every 2 minutes,
is faced with having to generate, encrypt and distribute as many as
3000 secret keys per hour (1200 milliseconds for each new key. These
HA functions of generating, encrypting and distributing the MN-FA
secret keys are in addition to all other HA activities. Can an HA
perform these KDC functions on top of its responsibilities for
handling traffic being tunneled to roaming MNs? Another problem is
how will the secret keys be distributed? Manual distribution of the
secret key will not scale as previously discussed. This approach
does not deal with the trust relationship between the MN and the FA
for access control and non-repudiation. Again a trusted third party
is necessary for the FA to trust the MN from an identity standpoint.
USING DIFFIE-HELLMAN WITH THE FOREIGN AGENT
This approach allows MNs and FAs to establish registration keys by
executing the Diffie-Hellman key exchange algorithm [Diffie76] as
part of the MN's registration. Using the Diffie-Hellman algorithm
allows the MN and the FA to establish a registration key without any
pre-existing mobility security associations. One is still faced with
the problem of manually distributing secret keys between MNs and HAs.
This approach also does not deal with the trust relationship between
the MN and the FA for access control and non-repudiation. Again a
trusted third party is necessary for the FA to trust the MN from an
identity standpoint.
USING A MOBILE NODE PUBLIC KEY
With this approach the FA is charged with generating the new
registration key and returning a copy of it encrypted with the MN's
Public Key, received in a MN Public Key extension. However the FA has
no way of verifying if the public key received from the MN is valid
for that MN since there is no authentication associated with the
Public Key sent by the MN. This approach also does not deal with the
trust relationship between the MN and the FA for access control and
non-repudiation. Again a trusted third party is necessary for the FA
to trust the MN from an identity standpoint.
USING A FOREIGN AGENT PUBLIC KEY
The only real difference between this approach and that of using the
Expires March 1, 1999 [Page 4]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
HA as a KDC is that the HA uses an unauthenticated Public Key from
the FA for encrypting the newly generated registration key being sent
to the FA rather that an existing secret key security association
between the HA and the FA. The inclusion of an MD5 digest of the FA's
public key in a Registration Key Request Public Key Digest extension
only establishes that the public key supplied by the FA in the FA
Public Key extension is the same as received by the MN in an Agent
Advertisement message.
1.3. Trusted Third Party needed
Use of public keys contained in Digital Certificates (Certificates)
issued by trusted third parties, in the form of Certificate
Authorities (CAs), provides the key ingredient for establishing trust
Relationships between HAs, MNs and FAs. When an FA receives a message
from an MN digitally signed with the MNs private key, the FA is able
to validate the digital signature using a copy of the MN's public key
from a copy of the MN's Certificate. If the FA shares the same CA as
the MN, then the FA can easily authenticate the MN's Certificate by
checking the CA digital signature within the MN's Certificate using
the CA's public key from the copy of the CA's Certificate already in
the FA's possession. Should the FA and the MN not use the same CA,
the FA can establish a trust hierarchy path between the FA's CA and
the CA of the MN. The converse is true for MNs authenticating digital
signatures generated with FA private key and the same is true between
HAs and FAs. The inclusion of the CA, or trust hierarchy path between
CAs, allows Mobile IP aware systems to establish strong trust
relationships to base authentication, access control and
non-repudiation decisions on.
1.4. Terminology
Certification Authority (CA)
A third party trusted by one or more users to create and assign
digital certificates. All CAs are required to maintain a
database of the Distinguished Names (DNs) which they have
certified and to take measures to ensure that they do not
certify duplicate DNs.
Certificate-Revocation List (CRL)
A data structure that contains 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 Distinguished Name (DN) contained within the Certificate.
Expires March 1, 1999 [Page 5]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
Digital Certificate (Certificate)
A Digital Certificate, or Certificate, is a data structure
that binds an entity's Distinguished Name (DN) 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.
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 RSA private key of the signer of the content.
Distinguished Name (DN)
A Distinguished Name, or DN, defines a "path" through an X.500
directory tree from the root of the tree to an object of
interest.
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.
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.
Expires March 1, 1999 [Page 6]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
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.
1.5. Security Enhancement
The design goal of the Public Key Authentication (PKA) model is to
add scaleable strong authentication to Mobile IP. The PKA enabled
Mobile IP protocol works exactly the same way as the base protocol
for the FA supplied card-of-address (COA) mode of operation except
for the mechanism responsible for generating/verifying message
authenticators and the data structures supporting the proposed
digital signature based authenticators.
The Co-located COA mode (sometimes referred to as "pop-up" mode)
relies on the use of DHCP [RFC1541] and cannot be considered
deployable on a wide scale since DHCP does not include any
authentication and 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. The typical uses of DHCP are to: 1) simplify IP address
management in an organizations LAN campus environment, or 2) allow
ISP customers to remotely connect to the ISP' infrastructure. ISPs
using DHCP require the connecting customer to provide a user ID and a
password before the ISP will accept user traffic from the connecting
customer.
2. Protocol Overview
Under the PKA model, a complete registration cycle consists of:
- the MN receiving a Mobility Agent Advertisement
- the MN sending a Registration Request to the FA
- the FA preprocessing the received Registration Request and, if
tentatively approved, passing the Registration Request to the MN's
HA
- the HA receiving the Registration from the MN via the FA
- the HA processing the Registration Request and sending a
Registration Reply to the FA
Expires March 1, 1999 [Page 7]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
- the FA receiving the Registration Reply, updating visiting MN data
structures, and 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. The primary
message change supporting the PKA model is the use of a Certificate
Extension appended to Mobile IP control messages (Mobility Agent
Advertisement Extension, Registration Requests and Registration
Replies).
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 issued by a Certificate Authority (CA) to the sender, or
forwarder, of a message. There may also be present in the Certificate
Extension Certificates belonging to one of more CAs. When FAs and MNs
share a common CA, only the Certificate of the common CA would ever
appear in the Certificate Extension. In the case where the FA and the
MN do not have a common CA, the Certificate Extension will contain
multiple CA Certificates from which a trust hierarchy path between
the CA of the MN and the CA of the FA may be established (see Section
4. For details on establishing trust hierarchy paths)
2.1 Agent Discovery
In the base protocol, 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 COA (which usually is the FA's address)from these
Mobility Agent Advertisement Extensions (Agent Advertisements).
The PKA model requires that the Agent Advertisement include a digital
signature that is used to authenticate the contents of the Agent
Advertisement message and a Certificate Extension so that prospective
MNs can quickly obtain an authentic copy of the FA's public key,
necessary to verify the digital signature. The specific
authentication steps the FA follows are:
1. the FA uses it's private key to produce a digital signature
spanning all Agent Advertisement message fields, as specified in
[RFC2002].
2. The FA creates a Certificate Extension placing a copy of its
Certificate and a copy of the Certificate belonging to FA's CA
into the Certificate Extension.
3. The FA also places copies of the Certificates of those CAs
necessary for an MN to establish a trust hierarchy path between
CAs into the Certificate Extension.
4. The FA appends the Certificate Extension to the Agent
Advertisement message (Extension).
5. The FA follows the base Mobile IP protocol regarding the
transmission of Agent Advertisement messages.
Expires March 1, 1999 [Page 8]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
2.2 MN Processing of Agent Advertisements
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 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 (see Section 5.0).
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, created using the FA's private key.
6. Upon successful verification of the Agent Advertisement digital
signature, the MN continues with normal processing of the Agent
Advertisement message as specified in the base Mobile IP
protocol.
7. 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
Agent Advertisement message.
2.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 uses it's private key to produce a digital signature
spanning all Registration Request message fields as specified in
Section 3.5.5 and places this digital signature in a Mobile
Authentication Extension.
2. The MN then creates a Certificate Extension placing a copy of its
Certificate and a copy of the Certificate of the MN's CA into the
Certificate Extension.
3. Should the MN and the FA not share a common CA, the MN also
places copies of the Certificates of those CAs necessary for the
FA to establish a trust hierarchy path between CAs.
4. The MN appends the Certificate Extension to the end of the
Registration Request message following the Mobile Authentication
Extension.
5. The MN continues with the actions specified in RFC2002 for
Expires March 1, 1999 [Page 9]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
sending out Registrations Requests.
2.4 Registration Request Authentication verification 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 (see Section 2.11) 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 Authentication
Extension, created using the MN's private key.
6. Upon successful verification of the Mobile 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
(see Section 2.5).
7. Should the Mobile 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 (see Section 2.11) informing the MN
that the MN's Registration Request is not allowed having failed
authentication.
2.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 uses it's private key to produce a digital signature
spanning all Registration Request message fields as specified in
Section 3.5.5 and places the digital signature in a Foreign
Expires March 1, 1999 [Page 10]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
Authentication Extension located following the Mobile
Authentication Extension.
3. The FA places a copy of its Certificate and a copy of the
Certificate belonging to FA's CA into a new Certificate
Extension.
4. Should the MN and the FA not share a common CA, then the FA also
places copies of the Certificates of those CAs necessary for the
HA to establish a trust hierarchy path between CAs.
5. The FA appends the Certificate Extension to the end of the
Registration Request message following the Foreign Authentication
Extension.
6. The FA continues with the actions specified in [RFC2002] for
sending out Registrations Requests.
2.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 Authentication
Extension, created using the FA's private key.
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 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
Expires March 1, 1999 [Page 11]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
message informing the FA and the MN that the MN's Registration
Request is not allowed having failed authentication.
2.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 HA uses it's private key to produce a digital signature
spanning all Registration Request message fields as specified in
Section 3.5.5 and places the digital signature in an Home
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 Authentication
Extension.
4. The HA continues with the actions specified in [RFC 2002] for
sending out Registrations Requests.
2.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. The FA already has
a validated copy of the Certificate for the HA's CA from when the
FA established the trust hierarchy path for the Certificate of
MN's CA since the MN and the HA will share a common CA.
2. The FA uses the HA's public key from the HA Certificate
to verify the digital signature in the Home Authentication
Extension, created using the HA's private key.
3. Upon successful verification of the Home 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 (see Section 2.9).
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.
2.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:
Expires March 1, 1999 [Page 12]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
1. The FA deletes the Certificate Extension.
2. the FA uses it's private key to produce a digital signature
spanning all Registration Reply message fields as specified in
Section 3.5.5 and places the digital signature in a Foreign
Authentication Extension following the Home Authentication
Extension.
3. The FA places a copy of its Certificate into a new
Certificate Extension.
4. The FA appends the Certificate Extension to the end of the
Registration Request message following the Foreign Authentication
Extension.
5. The FA continues with the actions specified in [RFC2002] for
sending out Registrations Replies.
2.10 MN Receipt of Registration Reply forwarded by FA
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 extracts the FA's Certificate from the Certificate
Extension.
2. The MN uses the FA's public key from the FA Certificate to verify
the FA digital signature in the Foreign Authentication Extension,
created using the FA's private key.
3. 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 Authentication Extension, created using the HA's
private key.
4. Upon successful verification of the Registration Reply message
digital signatures, the MN continues with normal processing of
the Registration Reply message as specified in the base Mobile IP
protocol except for authentication actions.
5. 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.
2.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 as specified in
Section 3.5.5 and places the digital signature into a Foreign
Authentication Extension appended to the Registration Reply.
2. The FA then creates a Certificate Extension placing a copy of its
Certificate into the Certificate Extension.
3. The FA appends the Certificate Extension to the end of the
Registration Reply message following the Foreign Authentication
Extension.
Expires March 1, 1999 [Page 13]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
4. The FA continues with the actions specified in [RFC2002] for
sending out Registrations Replies.
2.12 MN Receipt of Registration Reply Generated by FA
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 extracts the FA's Certificate from the Certificate
Extension.
2. The MN uses the FA's public key from the FA Certificate
to verify the FA digital signature in the Foreign Authentication
Extension, created using the FA's private key.
3. 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.
4. 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.
3. Message and Extension Formats
3.1 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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CA-Certificate-Length | CA-Certificate
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CA-Certificate, continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 10 (1 byte), identifies this as a Certificate Extension.
Ext Length: (2 bytes) The length of the Certificate Extension
in bytes.
set to 4 + value of Authenticator-Length field
+ value of Source-Certificate-Length field
+ value of CA-Certificate-Length field
Expires March 1, 1999 [Page 14]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
Sender-Certificate-Length: (2 bytes) Length in bytes of the
X.509 Type 3 formatted Certificate
of the message sender.
Sender-Certificate: (variable length), The X.509 Type 3
Formatted Certificate of the message sender
which contains the public key of the
message sender.
CA-Certificate-Length: (2 bytes) Length in bytes of the X.509
Type 3 formatted certificate of a
Certificate Authority (CA).
CA-Certificate: (variable length), The X.509 Type 3 formatted
certificate of a CA which contains the public
key of the CA used to sign Certificates.
3.2. 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| Auth Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Foreign Agent Digital Signature |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 16
Length (6 + 4*N + S), where N is the number of care-of addresses
Advertised and S is the length of the Digital Signature
used by an FA to authenticate the other fields in the
Mobility Agent Advertisement Extension.
Sequence Number
Unchanged from base Mobile IP protocol.
Registration Lifetime
Unchanged from base Mobile IP protocol.
Expires March 1, 1999 [Page 15]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
R Registration required. Registration with this foreign
agent (or another foreign agent on this link) is
required. Must be always set.
B Unchanged from base Mobile IP protocol.
H Unchanged from base Mobile IP protocol.
F Unchanged from base Mobile IP protocol.
M Unchanged from base Mobile IP protocol.
G Unchanged from base Mobile IP protocol.
V Unchanged from base Mobile IP protocol.
A Authorization by digital signature, MUST be set.
Auth Type
Identifies the cryptographic method (algorithm) and key
Length used to generate digital signatures. Valid
Authentication types are:
Auth. Type Key Length Digital Signature
Value Algorithm in bits Length in bytes
--------- --------- ---------- -----------------
101 RSA 512 64
102 RSA 1024 128
Other Authentication types will be defined in the future.
Care-of Address(es)
Unchanged from base Mobile IP protocol.
3.3. 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 is always relayed to the HA by the FA through which the MN is
registering.
IP fields:
Unchanged from base Mobile IP protocol.
UDP fields:
Source Port variable
Destination Port 434
Expires March 1, 1999 [Page 16]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
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 |S|B|r|M|G|V|A|t| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 1 (Registration Request)
S Unchanged from base Mobile IP protocol.
B Unchanged from base Mobile IP protocol.
r Reserved bit; sent as zero.
M Unchanged from base Mobile IP protocol.
G Unchanged from base Mobile IP protocol.
V Unchanged from base Mobile IP protocol.
A Authorization by digital signature, MUST be set.
t Reserved bit; sent as zero
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.
Expires March 1, 1999 [Page 17]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
Extensions
Usage is same as in base Mobile IP protocol except for
- Mobile-Home Authentication Extension which MUST be
included in all Registration Requests.
- Foreign-Home Authentication Extension which MUST be
included for all Registration Requests being forwarded
from an FA to an HA
- Certificate Extension which must be included on all
Registration Requests.
3.4. Registration Reply
A mobility agent (FA or HA) returns a Registration Reply message to an MN
which has sent a Registration Request (Section 3.3) message.
IP fields:
Source Address Unchanged from base Mobile IP protocol.
Destination Address Unchanged from base Mobile IP protocol.
UDP fields:
Source Port <variable>
Destination Port Unchanged from base Mobile IP protocol.
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 | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type 3 (Registration Reply)
Code A value indicating the result of the Registration
Request. See below for a list of currently defined Code
values.
Expires March 1, 1999 [Page 18]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
Lifetime
Unchanged from base Mobile IP protocol.
Home Address
Unchanged from base Mobile IP protocol.
Home Agent
Unchanged from base Mobile IP protocol.
Identification
Unchanged from base Mobile IP protocol.
Extensions
Usage is same as in base Mobile IP protocol except for
- Mobile-Home Authentication Extension which MUST be
included in all Registration Replies.
- Foreign-Home Authentication Extension which MUST be
included for all Registration Replies being forwarded
from an FA to an MN
- Certificate Extension which must be included on all
Registration Replies.
No new values defined for use within the Code field.
3.5. Mobile IP Authentication Extensions
3.5.1. Computing Authentication Extension Values
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.
The default authentication algorithm uses RSA and a 512 bit private
key to compute a 512-bit cryptographic "message digest" of the
registration message. The default digital signature is a 512-bit
value computed over the protected fields from the registration
message.
Note that the digital signature field itself and the UDP header are
NOT included in the computation of the digital signature value.
3.5.2. Mobile Authentication Extension
Exactly one Mobile Authentication Extension MUST be present in all
Registration Requests. The location of the extension marks the end
of the authenticated data.
Expires March 1, 1999 [Page 19]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
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 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node (MN) Digital Signature |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 32
Length 4 plus the number of bytes in the digital
signature.
Auth Type
Valid if the A bit set, in which case this field
identifies the cryptographic method (algorithm) and key
length used to generate digital signatures. Valid
Authentication types are:
Auth. Type Key Length Digital Signature
Value Algorithm in bits Length in bytes
--------- --------- ---------- -----------------
101 RSA 512 64
102 RSA 1024 128
Other Authentication types will be defined in the future.
Digital Signature (variable length) (See Section 3.5.1.)
3.5.3. Foreign Authentication Extension
This Extension MUST be included in Registration Requests being passed
from an FA to an HA or Registration Replies sent from an FA to a MN.
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 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Foreign Agent (FA) Digital Signature |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 33
Length 4 plus the number of bytes in the digital
signature.
Auth Type
Valid if the A bit set, in which case this field
identifies the cryptographic method (algorithm) and key
length used to generate digital signatures. Valid
Authentication types are:
Expires March 1, 1999 [Page 20]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
Auth. Type Key Length Digital Signature
Value Algorithm in bits Length in bytes
--------- --------- ---------- -----------------
101 RSA 512 64
102 RSA 1024 128
Other Authentication types will be defined in the future.
Digital Signature (variable length) (See Section 3.5.1.)
3.5.4. Home Authentication Extension
This Extension MUST be included in Registration Replies being passed
from an HA to an FA.
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 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent (HA) Digital Signature |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 34
Length 4 plus the number of bytes in the digital
signature.
Auth Type
Valid if the A bit set, in which case this field
identifies the cryptographic method (algorithm) and key
length used to generate digital signatures. Valid
Authentication types are:
Auth. Type Key Length Digital Signature
Value Algorithm in bits Length in bytes
--------- --------- ---------- -----------------
101 RSA 512 64
102 RSA 1024 128
Other Authentication types will be defined in the future.
Digital Signature (variable length) (See Section 3.5.1.)
3.5.5 Correct Sequence of Extension.
Mobile IP Extensions MUST occur in the following sequences.
For Registration Request sent from MN to FA:
Expires March 1, 1999 [Page 21]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
Registration Request
Mobile Authentication Extension
Certificate Extension
The digital signature in the Mobile Authentication Extension MUST
be generated over all the fields in the Registration Request
starting with the Type field (inclusively) and continuing through
the fields of the Mobile Authentication Extension ending with the
Auth Type field (inclusively) in the Mobile Authentication
Extension.
For Registration Request sent to HA from FA:
UDP Header
Registration Request
Mobile Authentication Extension
Foreign Authentication Extension
Certificate Extension
The digital signature in the Foreign Authentication Extension MUST
be generated over all the fields in the Registration Request
starting with the Type field (inclusively) and continuing through
the fields of the Mobile Authentication Extension and the Foreign
Authentication Extension ending with the Auth Type field
(inclusively) in the Foreign Authentication Extension.
For Registration Reply sent to FA from HA:
UDP Header
Registration Reply
Home Authentication Extension
Certificate Extension
The digital signature in the Home Authentication Extension MUST be
generated over all the fields in the Registration Reply starting
with the Type field (inclusively) and continuing through the
fields of the Home Authentication Extension ending with the Auth
Type field (inclusively) in the Home Authentication Extension.
For Registration Reply forwarded to MN from FA:
UDP Header
Registration Reply
Home Authentication Extension
Foreign Authentication Extension
Certificate Extension
The digital signature in the Foreign Authentication Extension MUST
be generated over all the fields in the Registration Reply
starting with the Type field (inclusively) and Home Authentication
Extension through the fields of the Foreign Authentication
Expires March 1, 1999 [Page 22]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
Extension ending with the Auth Type field (inclusively) in the
Foreign Authentication Extension.
For Registration Reply sent to MN from FA:
UDP Header
Registration Reply
Foreign Authentication Extension
Certificate Extension
The digital signature in the Foreign Authentication Extension MUST
be generated over all the fields in the Registration Reply
starting with the Type field (inclusively) and continuing through
the fields of the Foreign Authentication Extension ending with the
Auth Type field (inclusively) in the Foreign Authentication
Extension.
4. Certificates
All Certificates used with Mobile IP MUST include the following
Fields:
Distinguished Name - The Distinguished Name (DN) is the sender's
IP address in dot-decimal notation
(aaaa.bbb.ccc.ddd). The use of this field is
a variation of the DN approach defined in
[X.500] given that the identity that needs to
be verified, and bound to a specific public
key, is the IP address of the network
interface the MN, FA or HA uses in the
context of PKA Mobile IP.
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 as
defined in [X.500]
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
Expires March 1, 1999 [Page 23]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
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
5. 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.
6. Certificate Revocation Lists
Each digital certificate should be checked against the current
Certificate Revocation List (CRL) from the issuing CA to ensure that
revoked Certificate are not employed. PKA Mobile IP recognizes that
network performance could be seriously degraded if a receiving node
always retrieves the most recent CRL when ever a new Certificate is
received. Consequently, a node (be it an MN, FA or HA) should cache
received 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
Expires March 1, 1999 [Page 24]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
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).
Expires March 1, 1999 [Page 25]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
7. Security Considerations
Those implementations of Mobile IP which do not include
authentication Between the MN and the FA run the risk of denial of
service attacks. MIPv4 relies on the use of the Address Resolution
Protocol (ARP), which does not provide any authentication, for
intercepting packets destined for a traveling MN. 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 PKA Mobile IP provide a user tunable
staleness threshold the degree of risk becomes a user managed
function.
A. Patent Issues
As of the time of publication, there exists a patent that is
relevant to implementers of the Protocol extensions described
herein:
A.1. Massachusetts Institute of Technology Patent #4405829
Ronald L. Rivest, Adi Shamir, Leonard M. Adleman are the
co-inventors of U.S. Patent No. 4405829, assigned to the
Massachusetts Institute of Technology (MIT). The patent was filed
December 14, 1977 and will expire on December 15, 1999, at which
time the technology covered by the patent reverts to the public
domain.
Furthermore the US Government has rights to this technology pursuant
to Contract No. N00014-67-A-0204, awarded to the Department of the
Navy, and Grant No. MCS76-14249, awarded by the National Science
Foundation.
Should implementers wish to immediately proceed with implementing
commercial versions of PKA Mobile IP they may obtain a license from
RSA Data Securities Inc. for use of the RSA asymmetric public key
algorithm.
This statement is for the IETF's assistance in its standard-setting
procedure, and should not be relied upon by any party as an opinion
or guarantee that any implementation it might make or use would not
be covered by the MIT Patent and any other patents.
Expires March 1, 1999 [Page 26]
Internet Draft Mobile IP Public Key Based Authentication August 1, 1998
References
[Diffie76] Diffie, W., Hellman, M. E., "New directions in
cryptography", IEEE Transactions on Information Theory,
IT-22(6):644--654, November 1976.
[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.
[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.
Authors' Address
Questions about this memo can also be directed to:
Stuart Jacobs
Network Security Department
GTE Laboratories,
40 Sylvan Road,
Waltham, MA 02454, USA.
Phone: 781-466-3076
Fax: 781-466-2838
Email: sjacobs@gte.com
Expires March 1, 1999 [Page 27]