1

CPCP

Hisham Khartabil

XCON WG

IETF 60, San Diego

2nd August, 2004

hisham.khartabil@nokia.com

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

<rule id="1"> <conditions> <identity> <domain>example.com</domain> </identity> </conditions> <actions> <allow-conference-state>true</allow-conference-state>

<join-handling>allow</join-handling> </actions> <transformations/> </rule>

5

Common Policy (2/6)

• Conditions:• <identity> that has

• <id>• <domain> and <except>• <any>

• <unauthenticated>• <anonymous>• <has-been-referred>• <has-been-invited>• <has-been-in-conference>• <is-in-conference>• <key-participant>• <is-on-dialout-list>• <is-on-refer-list>• <floor-id>• <pin>• <password>

6

Common Policy (3/6)

• Actions:• <allow-conference-state>• <allow-floor-events>• <join-handling> with values

• Block, allow, confirm• <allow-refer-users-dynamically>• <allow-invite-users-dynamically>• <allow-modify-settings>• <allow-modify-information>• <allow-modify-time>• <allow-modify-authorization-rules>• <allow-modify-dol>• <allow-modify-rl>• <allow-modify-sc>• <allow-modify-fp>• <allow-modify-ms>• <allow-sidebar>• <allow-modify-dil>• <authenticate> with values

• None, asserted-id, shared-secret and certificate

7

Common Policy (4/6)

• Transformations• <is-key-participant>• <is-floor-moderator>• <show-conference-info>• <show-floor-holder>• <show-floor-requests>

8

Common Policy (5/6)

• Introduced PIN and password per conference and per individual user

• The <password> or <pin> element can be used to match those participants that are have knowledge on a password for the conference. For example:

<rule id="3"> <conditions> <password>pass1</password> </conditions> <actions> <join-handling>allow</join-handling> </actions> <transformations/> </rule>

• 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 <identity> condition and the <password> condition creates the possibility of assigning users personal passwords to enable them to join a conference. For example:

<rule id="4"> <conditions> <identity> <id>alice@example.com</id> </identity> <password>pass2</password> </conditions> <actions> <join-handling>allow</join-

handling> </actions> <transformations/> </rule>

10

Other Changes From 00 (1/3)

• Added text on how to use external lists• Removed use of wildcards (instead <domain> 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 <id> Element

• “The <identity> element is already defined in the common policy framework [1]. However, the rules for interpreting the identities in <id> elements are left for each application to define separately. This document, however, does not define the rules for interpreting identities in <id> 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 <id> elements?

15

Conference State Events

• <allow-conference-state> 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

• <allow-floor-event> allows or blocks a user to receive conference floor events

• Is this sufficient?

• Do we need “confirm”, “polite-block”?

17

Conference Information

• The <show-conference-info> element controls whether information in the <settings>, <time> and <info> 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

<any> vs. <unauthenticated>

• <any> in the draft refers to any authenticated user

• <unauthenticated> refers to any unauthenticated user

• The lack of <identity> element in the conditions means any user, so do we need <unauthenticated> 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 <authenticate> 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 (<any>, 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:

• <allow-modify-settings>• <allow-modify-information>• <allow-modify-time>• <allow-modify-authorization-rules>• <allow-modify-dol>• <allow-modify-rl>• <allow-modify-sc>• <allow-modify-fp>• <allow-modify-ms>• <allow-sidebar>• <allow-modify-dil>

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:

– <has-been-in-conference>– 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:

• <allow-modify-dol> needs the companion action <allow-read-dol> to allow users to read the Dial-out list but not modify it.

25

<time> vs. <validity> element

• Common policy has a <validity> condition that relates to the authorization rules. It defines the time period that a rule exists in

• <time> 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:

<rule id="4"> <conditions> <anonymous>

</conditions> <actions> <join-handling>allow</join-handling> </actions> <transformations/> </rule>

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

<rule id="4">

<conditions>

<identity>

<id>alice@example.com</id>

</identity>

<anonymous>

</conditions>

<actions>

<join-handling>allow</join-handling>

</actions>

<transformations/>

</rule>

• Do we mean <pseudonym> by <anonymous>? Or do we need both?

<rule id="4">

<conditions>

<identity>

<id>alice@example.com</id>

</identity>

</conditions>

<actions>

<join-handling>allow</join-handling>

</actions>

<transformations>

<provide-anonymity>

</transformation>

</rule>

28

<pin> and <password>

• Users who are using a PSTN phone to join a conference can authenticate using a PIN (traditional way). We use the <pin> 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 <password> 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, <pin> and <passwords> 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:

<dailout-list>

<target uri=“sip:bob@example.com”/>

</dailout-list>• Example of using external list:

<dailout-list>

<target uri=“http//xcap/resource-lists/alice/friends/~~/list[@name=“friends”]”/>

</dailout-list>• What does it mean for an <id> 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 <external> element or “external” attribute?

<dailout-list>

<target uri=“http//xcap/resource-lists/alice/friends/~~/list[@name=“friends”]” external=“true”/>

</dailout-list>

OR

<dailout-list>

<external uri=“http//xcap/resource-lists/alice/friends/~~/list[@name=“friends”]”/>

</dailout-list>

31

Unauthenticated Identities

• The <id> element in <identity> element refers to authenticated users only

• Do we need to list users that need to be authenticated? For example:

• User bob@example.com can join a conference, but he does not need to be authenticated? So anyone claiming to be Bob can join?

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

<rule id="1">

<conditions>

<identity>

<domain>example.com</domain>

</identity>

</conditions>

<actions>

<join-handling>allow</join-handling>

</actions>

<transformations/>

</rule>

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:

<rule id="2">

<conditions>

<identity>

<uri>bob@example.com</uri>

</identity>

</conditions>

<actions>

<join-handling>block</join-handling>

</actions>

<transformations/>

</rule>

34

Expelling a User

• So, in order to expel Bob, the original rule has to be modified using the <except> element:

<rule id="1">

<conditions>

<identity>

<domain>example.com</domain>

<except>bob@domain.com</except>

</identity>

</conditions>

<actions>

<join-handling>allow</join-handling>

</actions>

<transformations/>

</rule>

35

Floor-id

• Currently uses floor URI.

• Needs to be changed to reflect current floor control protocol