VCerf: Need for unforgeable user identification

[J Paul Holbrook <[e-mail]>]

Security Policy WG folks:

The following memo was written by Vint Cerf to address one of policy
topics we talked about at the Pittsburgh IETF in May.  I transcribed
this from Vint's hand-written draft; please blame any typos and the
formatting on me.  Forwarded with permission from Vint.
   
    Paul Holbrook

-----------------------------------------

Vint Cerf
CNRI
July 31, 1990 

The Need for Unforgeable User Identification

FIRST DRAFT

  Summary
  -------

This brief memorandum motivates the need for Internet mechanisms and
facilities for authenticating user identification and for assuring that
such identification cannot be forged.


  Introduction
  ------------

The Internet has reached a point in its evolution where some of the
services accessible require compensation from the using parties (or an
entity which accepts responsibility for paying for services rendered).

At the application level, such compensation is required for use of
information services such as bibliographic databases (National Library
of Medicine MEDLARS; Research Libraries Information Network, etc.)

Commercial electronic messaging providers (e.g. MCI Mail, Compuserve,

ATT Mail, Sprint Mail, BT Dialcom, QUIK-COMM, etc.) normally charge
for their services.  Some, such as Compuserve and MCI Mail provide
access to commercial information services (e.g. Dow Jones News &
Retrieval).  Under the present terms and conditions, commercial email
services do not charge Internet users for delivering email sent from
Internet sites to commercial email boxes.  Even if this provision
remains in place, there are other services such as fax and hardcopy
delivery, bulletin boards and information services which, at present,
are not accessible to Internet users because there is no secure way to
identify a billable account to which to charge these special services.

Passwords carried in plaintext form across the Internet, whether in a
Telnet session or via email, are not sufficiently protected to make
the risk of compromise acceptable.  Moreover, there is no currently
standardized means of authenticating whether the use of a particular
billable account is legitimate (once a password is compromised, it can
be used at will, for simple, password-based account identification
methods.)


  Example Requirements
 ---------------------

At least two applications need reliable, secure account authentication
capability:

	(1) remote login
	(2) email store and forward services

In the first instance, it is required that the user/account
identification provided to the server be protected from capture and
re-use by hostile third parties and that the serving site can verify
that the identification has not been forged.

In the second case, it is required that at an email relay, an arriving
message to be passed into the next email system can be reliably and
authentically associated with an account in the next email system, if
necessary, for purposes of accounting and validation that the message
originator is authorized to use the services requested.

For example, it should be possible for an Internet user to send email
to fax recipients by way of ATT Mail and for ATT Mail to correctly
account and bill for this usage.  This means that the originator must
supply information associated with a message which identifies
                   ----------
account information needed to complete processing of the message at
the Internet/commercial email interface.  The provision of this
account identifying information needs protection from compromise and
validation that its use is legitimate.

  Questions
  ---------

1. Can the same techniques work for remote login and store-and-forward
services?

2. Even if a "password" can be encrypted for confidentiality and
signed for authenticity, how can the recipient be sure that the
encrypted and signed object has not been hijacked by an abusing third
party?  (i.e. "stealing and reuse")

3. Given that there must be some kind of authenticated exchange
between user and server just to set up an account, can we take
advantage of this to carry out any additional exchanges needed to
support the confidentiality and authenticity required for these
account validation applications?