Upload
cori-sharp
View
217
Download
1
Tags:
Embed Size (px)
Citation preview
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>[email protected]</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>[email protected]</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>[email protected]</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:[email protected]”/>
</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 [email protected] 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>[email protected]</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>[email protected]</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