Subject: [XCON] WGLC: Conferencing Scenarios

From: Adam Roach <[email-masked]>
Date: Tue, 09 Aug 2005 11:54:17 -0500

Today begins a three-week working group last call period for the 
Conferencing Scenarios document:

http://www.ietf.org/internet-drafts/draft-ietf-xcon-conference-scenarios-04.txt

The chairs plan to submit the document to the IESG for consideration 
shortly after this last call closes unless substantial issues are 
discovered. This last call ends on August 31st. Comments should be 
directed to this mailing list.

/a

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 12 Aug 2005 14:03:28 +0300

Hi:

In general I am fine with this document. Perhaps my only concern is 
about the paragraph that discusses the Authentication of Participants in 
Section 3.5. This paragraph reads:

       Authenticate participants - A participant can authenticate other
       participants who want to join the conference.  This can be done
       implicitly by assigning a password to the conference and letting
       the Conferencing System authenticate the new participants or
       explicitly by directing the authentication requests to the
       initiating participant who authenticates each participant.

If we consider that authentication is the process of presenting an 
identity and verifying that it belongs to the entity that presents it, I 
don't see how a conference participant can ***authenticate*** other 
participants. Further more, I don't agree that "This can be done 
implicitly by assigning a password to the conference ... ".

I think this paragraph is missing two or three things

a) On one side, the conference system will typically authorize some 
users to joining the conference. This can be done by assigning a shared 
secret to the conference. The conference system requests the 
participants to show that they are in possession of the secret, as part 
of the authorization process, but still, the conference system may not 
know the identity of the participant (e.g., anonymous or unauthenticated 
participants).

b) On another side, the Conference System may want (if possible) 
authenticate the participant. This can be done by the any of the various 
authentication mechanisms presents in SIP today (auth-body, 
P-Asserted-Identity, SAML, you name it). Note that this might not always 
be possible (e.g., the P-Asserted-Identity requires a trust domain that 
will not always be in place). And note also that this process is 
independent of having the shared secret to join the conference (e.g., 
the conference system authenticates me, but I don't know the id/password 
of the conference).

c) A third issue is if a participant can authenticate another 
participant. And I see two ways to achieve this point:

c.1) one is and out-of-band mechanism that involves the two participants 
directly (for example, auth-body or something like that).

c.2) the other is, if one participant has been authenticated by 
Conference System, then the Conference System can inform of his 
authenticated identity (e.g., through the conference event package). 
Note that this requires some trust from the participant to the 
conference system.

Comments? at least I think that the current text is quite misleading. 
Perhaps some explanation on the above lines will be useful.

----

Some typos as well:

- s/Recoreders/Recorders
- s/recored/recorded
- s/aprticipant/participant
- s/A participant is the conference may be/A participant in the 
conference may be/

Br,

         Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland