Subject: RE: [XCON] WGLC: Conferencing Scenarios

From: "Even, Roni" <[email-masked]>
Date: Mon, 15 Aug 2005 11:33:27 +0300

Miguel,
I think that we are talking about the same thing and the text in the
document is using the wrong terminology.

I would try to present the cases of authorization and authentication as
you mentioned in your case a,b and c.

Roni  

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Monday, August 15, 2005 9:44 AM
To: Even, Roni
Cc: XCON-IETF; [email-masked]
Subject: Re: [XCON] WGLC: Conferencing Scenarios

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

Even, Roni wrote:

> 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