Browse Prior Art Database

Distributed-protocol authentication scheme (RFC1004)

IP.com Disclosure Number: IPCOM000001807D
Original Publication Date: 1987-Apr-01
Included in the Prior Art Database: 2019-Feb-15
Document File: 8 page(s) / 12K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D.L. Mills: AUTHOR

Related Documents

10.17487/RFC1004: DOI

Abstract

The purpose of this RFC is to focus discussion on authentication problems in the Internet and possible methods of solution. The proposed solutions this document are not intended as standards for the Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to authentication problems, leading eventually to the adoption of standards. This document suggests mediated access-control and authentication procedures suitable for those cases when an association is to be set up between users belonging to different trust environments.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 16% of the total text.

Network Working Group D.L. Mills Request for Comments: 1004 University of Delaware April 1987

A Distributed-Protocol Authentication Scheme

Status of this Memo

The purpose of this RFC is to focus discussion on authentication problems in the Internet and possible methods of solution. The proposed solutions this document are not intended as standards for the Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to authentication problems, leading eventually to the adoption of standards. Distribution of this memo is unlimited.

1. Introduction and Overview

This document suggests mediated access-control and authentication procedures suitable for those cases when an association is to be set up between multiple users belonging to different trust environments, but running distributed protocols like the existing Exterior Gateway Protocol (EGP) [2], proposed Dissimilar Gateway Protocol (DGP) [3] and similar protocols. The proposed prcedures are evolved from those described by Needham and Shroeder [5], but specialized to the distributed, multiple-user model typical of these protocols.

The trust model and threat environment are identical to that used by Kent and others [1]. An association is defined as the end-to-end network path between two users, where the users themselves are secured, but the path between them is not. The network may drop, duplicate or deliver messages with errors. In addition, it is possible that a hostile user (host or gateway) might intercept, modify and retransmit messages. An association is similar to the traditional connection, but without the usual connection requirements for error-free delivery. The users of the association are sometimes called associates.

The proposed procedures require each association to be assigned a random session key, which is provided by an authentication server called the Cookie Jar. The procedures are designed to permit only those associations sanctioned by the Cookie Jar while operating over arbitrary network topologies, including non-secured networks and broadcast-media networks, and in the presence of hostile attackers. However, it is not the intent of these procedures to hide the data

Mills [Page 1]

RFC 1004 April 1987

(except for private keys) transmitted via these networks, but only to authenticate messages to avoid spoofing and replay attacks.

The procedures are intended for distributed systems where each user i runs a common protocol automaton using private state variables for each of possibly several associations simultaneously, one for each user j. An association is initiated by interrogating the Cookie Jar for a one-time key K(i,j), which is used to encrypt the checksum which authenticates messages exchanged between the users. The initiator then communicates the key to its associate as part of a connection establishment procedure such as described in [3].

The information being exchanged in this protocol model is largely intended to con...

Processing...
Loading...