GSS-API in multiconferencing

[Eric DELACOUR <[e-mail]>]

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