GSS-API in multiconferencing

Eric DELACOUR <eric.delacour@sept.fr> Tue, 08 October 1996 10:21 UTC

Received: from cnri by ietf.org id aa27739; 8 Oct 96 6:21 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06068; 8 Oct 96 6:21 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP id <JAA06620@pad-thai.cam.ov.com>; Tue, 8 Oct 1996 09:45:27 GMT
Received: from xr3.atlas.fr 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 xr3.atlas.fr 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, 8 Oct 1996 14:41:51 +0200
X400-Originator: eric.delacour@sept.fr
X400-Recipients: cat-ietf@mit.edu, fimeccou@synergia.fr
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 <eric.delacour@sept.fr>
Message-Id: <84476771193910001DELACOUR*/G=eric/S=delacour/PRMD=sept/ADMD=ATLAS/C=FR/@MHS>
To: Non Receipt Notification Requested <cat-ietf@mit.edu>
Cc: christophe <fimeccou@synergia.fr>
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.

Eric DELACOUR
France Te'le'com/SEPT CAEN