GSS-API in multiconferencing

Eric DELACOUR <> Tue, 08 October 1996 10:21 UTC

Received: from cnri by id aa27739; 8 Oct 96 6:21 EDT
Received: from by CNRI.Reston.VA.US id aa06068; 8 Oct 96 6:21 EDT
Received: from MIT.EDU by (8.7.5/) with SMTP id <>; Tue, 8 Oct 1996 09:45:27 GMT
Received: from by MIT.EDU with SMTP id AA19952; Tue, 8 Oct 96 05:45:20 EDT
X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Tue, 8 Oct 1996 11:44:59 +0200
X400-Received: by mta in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Tue, 8 Oct 1996 11:44:59 +0200
X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Tue, 8 Oct 1996 11:44:51 +0200
X400-Received: by /PRMD=sept/ADMD=ATLAS/C=FR/; Relayed; Tue, 8 Oct 1996 14:41:51 +0200
Date: Tue, 08 Oct 1996 14:41:51 +0200
X400-Mts-Identifier: [/PRMD=sept/ADMD=ATLAS/C=FR/;84476771193910001DELACOUR]
X400-Content-Type: P2-1984 (2)
Content-Identifier: UCOMX
Alternate-Recipient: Allowed
From: Eric DELACOUR <>
Message-Id: <84476771193910001DELACOUR*/G=eric/S=delacour/PRMD=sept/ADMD=ATLAS/C=FR/@MHS>
To: Non Receipt Notification Requested <>
Cc: christophe <>
Subject: GSS-API in multiconferencing

We implement GSS-API in the following environment:
-use: teleconferencing between PCs;
-security support: smart card.
(With regard to J. Linn's reply to my last message) our view of GSS-API applied to multi-party environment is not as complex as draft-barton-gss-api-sec-party-00.txt. Our concern is to avoid addition of new primitives specific to our application, and to keep GSS-API as generic and versatile as possible. Thence it is used as follows:
-A party, who plays a leader role, initiates the first call to gss-init-sec-context, in order to authenticate the first of the other participants; the value of context-handle is GSS-C-NO-CONTEXT.
-Whenever a new participant is connected, the authentication process is renewed between the leader and this participant, with a value of context-handle (as input) set (at the leader side) to the value established for the first authentication exchange. The structure addressed by this handle contains e.g. a context identifier, a conference identifier and a session key which is distributed (in protected form) within the initial context token, and which is common to the participants of a conference.
It is the responsibility of the application, or of an application element, to manage a list of participants and update it whenever a new party connects to the conference.
The user credentials are stored in a protected zone of a memory card and not in software. The "credential handle" is therefore reduced to a reference to this support.
We are interested in comparing this solution with existing implementations.

France Te'le'com/SEPT CAEN