1 / 35

CPCP

CPCP. Hisham Khartabil XCON WG IETF 60, San Diego 2 nd August, 2004 hisham.khartabil@nokia.com. Requirements. Went through a WGLC

melaraj
Download Presentation

CPCP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. <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> Providing Anonymity (2/2)

  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

More Related