1 CPCP Hisham Khartabil XCON WG IETF 60, San Diego 2 nd August, 2004

2 Requirements Went through a WGLC The main issue was the definitions of terms defined in draft- ietf-sipping-conferencing-framework-02 and how they related and are used in this requirements draft. Requirements draft does not reference the framework draft for definitions Framework draft does not define Floor Control Policy and that it is part of conference policy Framework defines conference policy to include media policy, yet no media policy requirements are present

3 Solution

4 Common Policy (1/6) Introduced and Extended Common Policy to replace ACL and PCL example.com true allow

5 Common Policy (2/6) Conditions: that has and

6 Common Policy (3/6) Actions: with values Block, allow, confirm with values None, asserted-id, shared-secret and certificate

7 Common Policy (4/6) Transformations

8 Common Policy (5/6) Introduced PIN and password per conference and per individual user The or element can be used to match those participants that are have knowledge on a password for the conference. For example: pass1 allow So the condition is the password. If any user knows the password, ignoring their identity, the user is allowed to join.

9 Common Policy (6/6) A combination of the condition and the condition creates the possibility of assigning users personal passwords to enable them to join a conference. For example: pass2 allow

10 Other Changes From 00 (1/3) Added text on how to use external lists Removed use of wildcards (instead in common- policy is used) Removed all but 1 namespace from XML Schema Added Refer-list Changed URI assignment and conflicts solutions to mirror that of list-usage in SIMPLE Moved conference manipulation text into a separate section making the XCAP section minimal (less than a page) Declared that interface between focus and conference policy server is out of scope Introduced the concept of sidebars, sidebar URIs etc. Changed media-policy to media-streams and introduced media-policy reference (Cullen Jennings' draft)

11 Other Changes From 00 (2/3) Fixed floor policy to enable correlation between media and floor Solved Key participant issue with common-policy Made major changes to conference-time reflecting list consensus Added privileges using common policy Simplified the schema for Dial-out list Changed the schema so the word "conference" does not appear in every element Added a section indicating where in the schema extensions are allowed Made Privileged user the common term replacing policy manipulator, and in some cases creator.

12 Other Changes From 00 (3/3) made consistent when to use single quotes, double quotes and <> in schema discussion text Populated the Security section with text Modified examples to reflect recent changes. Split examples into Conference policy example and XCAP example

13 Open Issues

14 Interpreting the Element “The element is already defined in the common policy framework [1]. However, the rules for interpreting the identities in elements are left for each application to define separately. This document, however, does not define the rules for interpreting identities in elements in conferencing applications since those interpretation rules are signalling protocol specific.” Do we need to say more than this? Specifically, how do you derive the identities (from different using protocols) used in the elements?

15 Conference State Events allows or blocks a user from subscribing to conference state event package Is this sufficient? Do we need “confirm”, “polite-block”? Do we need to break conference state into pieces and authorise certain pieces of state and not others?

16 Floor Control Events allows or blocks a user to receive conference floor events Is this sufficient? Do we need “confirm”, “polite-block”?

17 Conference Information The element controls whether information in the, and elements may be made available publicly. Do we require more granularity for this element? Perhaps an enumerated integer type, with defined levels of information about the conference, or a set of boolean transformations, each granting a single piece of conference information?

18 The need for Refer List In the last XCON meeting, we agreed that a separate refer list is needed, mainly because The list is not a list of users that the focus invites to join the conference (dial-out list) The ACL (now using common policy) is not the place to list users a focus refers to the conference

19 vs. in the draft refers to any authenticated user refers to any unauthenticated user The lack of element in the conditions means any user, so do we need explicitly?

20 Media Stream Security Policy Currently, the draft defines what security measures are needed for the signalling protocol (use of TLS and S/MIME) But what about the media? Do we need to include security policy for media? For example: Audio MUST use SRTP? Can it be a general media security policy or does it have to be per media type? Is this part of media policy? Is is local policy at the focus?

21 Authenticating a User The action defines the mechanism used by the conference focus to authenticate a user. This element is an enumerated integer type, with defined values of: none, asserted-id, shared-secret and certificate. We already have the necessary tools in conditions (, conditions without identities) Is this really useful? What benefit does it have to the average user?

22 Meta Policy (1/3) Many actions are defined that dictate the privileges for users in a conference:

23 Meta Policy (2/3) Should such a policy be defined in a separate document? The separate document indicates the privileged users and their privileges. Advantages: Reduces conference policy complexity Separates the manipulation rules of the conference policy from the conference policy itself Disadvantages: Many of the conditions have to be repeated in this new document. For example: – –Or should this just be using identity? (I.e. privileges are only assigned for identities) A user has to create and manipulate 2 documents.

24 Meta Policy (2/3) The current draft defines write access and assumes read access to users with write access Should there be separate actions defining read access? For example: needs the companion action to allow users to read the Dial-out list but not modify it.

25 vs. element Common policy has a condition that relates to the authorization rules. It defines the time period that a rule exists in element defines the conference lifetime There are cases where a rule might be valid for a portion of the conference time (eg: first half is management only and second half is for everyone in engineering)

26 Providing Anonymity (1/2) Currently a user requests anonymity by authenticating himself to the conference focus and providing an anonymous ID in the signalling protocol (like in the From-header). The conference policy needs to allow anonymous users to join by having a rule allowing it. For example: allow Should there be rules allowing specific users to be anonymous? If so, should there be a condition or transformation to provide anonymity? Or Both

27 Providing Anonymity (2/2) allow Do we mean by ? Or do we need both? allow

28 and Users who are using a PSTN phone to join a conference can authenticate using a PIN (traditional way). We use the condition for this. Users who are aware of the conference password can join, irrespective of their identity. So anyone who knows the password was join. We use the condition for this. Can we combine? The problem here is that it will create confusion since a user creating those pins or passwords will mistakenly put characters in a pin or think that a password is restricted to digits. They serve different purposes and it doesn't hurt to keep them separate BTW, and should be of type digit and string respectively.

29 External Lists (1/2) Currently, the draft states that to use an external list, you just place the list URI (XCAP) into the element that carries the URI Example of normal case: Example of using external list: What does it mean for an element to carry an XCAP URI?

30 External Lists (2/2) Should the use of external list be more explicit in the policy by using element or “external” attribute? OR

31 Unauthenticated Identities The element in element refers to authenticated users only Do we need to list users that need to be authenticated? For example: User can join a conference, but he does not need to be authenticated? So anyone claiming to be Bob can If we allow such a thing, how many Bobs do we allow? I.e. How many are allowed to claim to be Bob and can join?

32 Expelling a User Care must be taken since if one rules allows a user to join and one blocks a user from joining, the result in that the user is allowed to join. For example, Bob can join a conference since an authorization rule has been defined to allow everyone at example.com: example.com allow

33 Expelling a User Setting the following rule will not block Bob from joining nor will it expel him since the above rule overrides it: block

34 Expelling a User So, in order to expel Bob, the original rule has to be modified using the element: example.com allow

35 Floor-id Currently uses floor URI. Needs to be changed to reflect current floor control protocol