Subject: RE: [XCON] WGLC: Conferencing Scenarios

From: "Even, Roni" <[email-masked]>
Date: Mon, 15 Aug 2005 09:23:02 +0300

Miguel,
Thanks
For the reading the drafts and finding the typos, I will fix them

As for the comment.
The document is a scenario document and not describing a solution. I can
give you a simple way for the initiating participant to authenticate the
joining users. The conference bridge will create a sidebar between the
new participant the initiator who can ask the new participant or even
see him in video conference. Another way can be based on the recorded
name from the IVR before the user joins the conference. 

Roni

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Friday, August 12, 2005 2:03 PM
To: XCON-IETF
Cc: Even, Roni; [email-masked]
Subject: Re: [XCON] WGLC: Conferencing Scenarios

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

Adam Roach wrote:

> 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
> 

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

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

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 15 Aug 2005 09:43:30 +0300

Hi Roni:

I agree with your use case. But I think  the text in the draft is still 
misleading, it says that a participant can authenticate another 
participant "by assigning a password to the conference and letting the 
conferencing system authenticate the new participats". As I indicated in 
my previous e-mail, the password to the conference does nto generally 
authenticate the participant.

In addition to this, I understand that the text in the draft is 
addressing the case where a participant wants to authenticate other 
participants (sidebar case that you mention). But does not cover other 
authentication cases, such us those I mentioned earlier. I believe those 
  should be mentioned for completeness.

BR,

        Miguel