Network Working Group Scott Bradner
Harvard University
Allison Mankin
USC/ISI
Jeffrey I. Schiller
Massachusetts Institute of Technology
July 2002
A Framework for Purpose Built Keys (PBK)
<draft-bradner-pbk-frame-01.txt>
Status of this Memo
This document is an Internet-Draft and is subject to the 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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This memo considers a particular class of the need to authenticate
the source of a network communication. The class consists of those
cases where the actual identity of the source is not important but
the knowledge that the source is the same one as started the
communication and the assurance that the source cannot be spoofed are
important. This memo defines the use of specially generated
public/private key pairs, known as Purpose Built Keys (PBKs), to
Bradner, Mankin & Schiller [Page 1]
Purpose Built Keys Framework July 2002
provide this knowledge and assurance. This memo is not a full
specification of a PBK protocol, but rather a model or framework for
development of PBK in applications.
1.0 Introduction
There are many cases in Internet protocols where cryptographic
mechanisms can add significant security improvement. However most
such mechanisms rely on associating keys to entities, ultimately
requiring an enterprise-wide, multi-enterprise, or even more widely
deployed Public Key Infrastructure (PKI).
In the absence of security mechanisms, many protocols are
continuously vulnerable to attack.
However there are many circumstances where we can improve overall
security by narrowing the window of vulnerability, so that if we
assume that some operation is performed securely, we can secure all
future transactions.
There are also cases where the actual identity of the initiator of a
network communication is not an important piece of information, yet
it is important to know that successive packets are from that same
source. One example of this is in mobile IPv6. Mobile IPv6 contains
a rebinding option that enables a mobile node to tell the other end
of a communication that the IP address for the mobile node has
changed. It is clearly important to know that any such rebinding
request actually came from the correct mobile node even if the
identity of the user of that mobile node does not need to be known.
Note that it is not that the identity of the user here is unimportant
to the network (the node user may well authenticate to a a AAA
service or other access manager at the start of network activity),
but rather that it is unimportant to accomplish that level of
authentication for the purpose of rebinding. Another example of this
class of authentication would be continuing a connection through
local renumbering of its site.
This memo describes the use of a temporary public/private key pair
which is generated by a host for each case where the consistency of
authentication needs to be assured. For example, a new key pair
would be generated before each mobile IP session and discarded when
the session was complete.
This use of these host-generated temporary keys is confined to the
parties in a communication and does not require that the keys be
registered with or known by any third party. Thus this mechanism
Bradner, Mankin & Schiller [Page 2]
Purpose Built Keys Framework July 2002
does not require that any support infrastructure exist outside of the
protocol support in the corresponding hosts and can be deployed
incrementally as host support becomes available. It also scales well
since the operations are confined to the end systems involved in the
communication.
By not using registered keys, this mechanism preserves user anonymity
as long as the identity of the users are not obtained by some other
process during the communication.
By using a challenge-response confirmation step, this mechanism can
work in environments where the IP addresses in the packet stream
could be modified in the path between the correspondents. The
challenge-response makes it much harder for a man-in-the-middle
attacker to issue requests in the name of a correspondent.
The PBK mechanism does not require the use of a reliable protocol.
It is intended to be able to fit under transports or under
applications. It differs from IPSec in that it is applied on demand
by an application or transport.
When this mechanism is used with applications the PBK's public key
can be used in an identity for a web-cookie like function, but the
use is under the control of the node that initiates the connection
rather than under the control of the server.
2.0 Conceptual Overview
Following is a conceptual step-by-step description of the PBK process
when operating below the transport layer.
First some definitions:
initiating node: the node initiating the conversation
receiving node: the node at the other end of the conversation
Before an initiating node initiates a connection during which it will
need to prove that it is the same node that started the connection,
it creates a public/private key pair for use during the connection.
This is known as a purpose-built key (PBK) pair.
The initiating node then creates a Purpose-Built ID (PBID) by
performing a cryptographic hash of the public part of the PBK. This
PBID will be used as an identity token for the node.
The initiating node then initiates the connection. The PBID is sent
along with the initial packets in the connection. In IPv6 this could
be done in an end-to-end option header, in IPv4 as a header option.
(These option ideas are for transport level use of the PBK - if the
Bradner, Mankin & Schiller [Page 3]
Purpose Built Keys Framework July 2002
PBK was used from within HTTP or another application, the PBID's
location would be in the application.). The PBID does not need to
appear in all of the packets; it just has to be reliably conveyed to
the receiving node. Reliability may be obtained by carrying it on
enough packets so that a return packet indicates it was received
eventually. This is the simplest approach; depending on requirements
and the application, the PBID may well be transported reliably.
The receiving node stores the PBID and the source IP address in the
received packet in a table.
At some time in the connection before the proof of identity is
needed, the initiating node sends its public key to the receiving
node. This again could be done in IP-level options or in an
application-level exchange. The receiving node verifies that the
received public key hashes to the previously provided PBID.
When the initiating node wants to perform some operation, such as a
mobile IPv6 address rebinding, it sends the operation request along
with the PBID. The message is signed using the private part of the
PBK. If replay protection is necessary, a nonce value (a
monotonically increasing value) or timestamp may be included with the
operation request.
When the receiving node gets such an operation request it verifies
the digital signature and sends a challenge packet to the initiating
node using the source IP address in the packet with the request as
the destination address. The challenge packet contains a random
number test value generated by the receiving node.
When the initiating node receives the challenge packet it encrypts
the test value in its private key and sends the result back to
receiving node.
When the receiving node gets the challenge response it decrypts the
test value using the stored public key associated with the PBID. If
the results match then the receiving node can be sure that the node
that sent the operation request was the correct initiating node.
The PBKs would normally be discarded at the end of the communication
but in those cases where a continuity of identity is needed over
multiple sessions the PBKs could be retained until the requirement
was over.
3.0 Notes on the design
The hash of the public key is used as the PBID so that the
relationship between an offered PBID and public key can be
Bradner, Mankin & Schiller [Page 4]
Purpose Built Keys Framework July 2002
established. If a receiving node is in possession of the private key
and the hash of the corresponding public key matches an offered PBID,
it can be sure that it has the correct PBID for that public key.
Retransmission algorithms, where they are needed, must be conformant
with RFC 2914 [RFC2914].
In the cases where commands could be issued by both ends of a
communication, as would be the case in mobile IPv6 if both ends were
mobile, separate PBKs would be created by each end and the mechanism
would be run independently by each end.
3.0 Security Considerations
This whole document is about how to perform authenticated operations
in an environment where there is no security infrastructure and one
where network addresses might change during the communication.
In the absence of infrastructure, it is not always possible to
authenticate one party to another. In the absence of any
cryptographic security mechanism, internet transactions are
continuously at risk of compromise. With PBKs it is possible to
leverage an initial "leap of faith" so that presuming an initial
transaction has not been tampered with (say the exchange of PBID's at
the beginning of an association between two parties), future
transactions can be secured.
6.0 Author's Addresses
Scott Bradner
Harvard University
Cambridge MA 02138
Phone +1 617 495 3864
email sob@harvard.edu
Allison Mankin
University of Southern California, Information Sciences Institute
4350 N. Fairfax Drive, Suite 620
Arlington, VA 22203
Phone: +1 703 812 3706
email: mankin@isi.edu
Jeffrey I. Schiller
Massachusetts Institute of Technology
MIT Room W92-190
Bradner, Mankin & Schiller [Page 5]
Purpose Built Keys Framework July 2002
77 Massachusetts Avenue
Cambridge, MA 02139-4307
Phone: +1 617 253 0161
email: jis@mit.edu
Informative References
[RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914,
September 2000.
Moskowitz, R., "Host Identity Payload Architecture", "Host Identity
Payload Protocol", http://homebase.htt-consult.com/~hip, 2001.
Full Copyright statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on An
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Bradner, Mankin & Schiller [Page 6]