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 ; 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 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. Eric DELACOUR France Te'le'com/SEPT CAEN   Received: from cnri by ietf.org id aa21689; 17 Oct 96 14:48 EDT Received: from mx1.cac.washington.edu by CNRI.Reston.VA.US id aa18684; 17 Oct 96 14:48 EDT Received: (from daemon@localhost) by mx1.cac.washington.edu (8.7.5+UW96.10/8.7.3+UW96.09) id KAA18804 for imap-out; Thu, 17 Oct 1996 10:58:13 -0700 Errors-To: owner-imap@cac.washington.edu Sender: owner-imap@cac.washington.edu Received: from prowler.isocor.com (prowler.isocor.com [198.6.228.65]) by mx1.cac.washington.edu (8.7.5+UW96.10/8.7.3+UW96.09) with ESMTP id KAA18799 for ; Thu, 17 Oct 1996 10:58:09 -0700 From: Roy.Schroeder@isocor.com Received: by prowler.isocor.com (1.0.240); 17 Oct 1996 10:59:15 -0700 X400-Received: by mta USENG in /PRMD=isocor/ADMD=telemail/C=us; Relayed; 17 Oct 1996 10:59:14 -0700 Date: 17 Oct 1996 10:59:14 -0700 Delivery-Date: 17 Oct 1996 10:59:15 -0700 Message-Type: Multiple Part X400-Originator: Roy.Schroeder@isocor.com X400-MTS-Identifier: [/PRMD=isocor/ADMD=telemail/C=us;ISOCOR-3262fda5-PROWLER] X400-Recipients: imap@CAC.Washington.EDU Original-Encoded-Information-Types: IA5-Text X400-Content-Type: P2-1984 Message-ID: <"ISOPRO-1.60.056::DH-NO::6931::3267475D"*/G=Roy/S=Schroeder/O=eng/PRMD=isocor/ADMD=telemail/C=us@MHS> Importance: normal Subject: minor point - Value of CR is incorrect Autoforwarded: FALSE To: Non Receipt Notification Requested CC: Non Receipt Notification Requested Priority: normal Conversion: Allowed Conversion-With-Loss: Allowed Alternate-Recipient: Allowed Content-Identifier: minor point - V On page 67 of the latest draft (internet-drafts/draft-crispin-imap-base-06.txt October 1996) it defines CR as CR ::= The normal code for US ASCII CR is 0x0D, not 0x0C. This error has been in all the IMAP4 FRCs. It should probably be corrected before final acceptance. Regards ---------------------------------------- Roy A. Schroeder Program Manager, ISOCOR Tel: +1 (310) 581-8100-FAX: +1 (310) 581-8111 X.400:c=us;a=telemail;p=isocor;g=roy;s=schroeder Internet: roy.schroeder@isocor.com