Dispatch IETF82 ================ Tuesday November 15th, 2012 13:00-15:00, Room 201DEF, Taipei, Taiwan Chaired by: Cullen Jennings and Mary Barnes Notetakers: Jean Mahoney, Christer Holmberg Jabber Scribe: Hadriel Kaplan Conclusions: 1) Remote Call, Device Control: There is interest in the work, but concerns over the scope, as well as the under specification of security impacts and whether SIP will be used. One suggestion was to charter the group to do the work in stages - i.e., define device control, call control, the model and security, but not consider a solution until after that work is done. The proposed charter revisions (for scope and security) are to be discussed/agreed on the mailing list. In addition, feedback and input from the ADs is required to ensure this will fly when it goes to the IESG. 2) Referencing and Verifying User Attributes: There is some interest in solving the problem of determining "good" requests from unknown or privacy-blocked recipients. Discussion to continue on the mailing list. Note that an unofficial discussion for the STRAW WG proposal is include included in the proceedings and in the recordings for this meeting. Link to audio file at: http://www.ietf.org/audio/ietf82/ Link to Meetecho full multimedia recordings (including jabber): http://ietf82.conf.meetecho.com/index.php/Recorded_Sessions ======================================================================== Detailed Notes (Jean Mahoney): ======================================================================== 13:00-13:10 Chairs Status and agenda bash minute takers - Christer and Jean Note well SIP Continuation was removed from agenda because the presenters didn't confirm. Wiki needs to be updated. New working group - bfcpbis - meeting on Wed morning Deadlines presented Need to discuss infrastructure overlay Mark - want to ensure just one overlay. Cullen - please read the draft and comment on the list Magnus has created a media stream selection draft. Please read and comment. Where to dispatch this? Seeds for 83 topics SIP forum - want to test SIPconnect 1.1 in Jan at Cablelabs. - 2012 SIPnoc STRAW wg proposal Agenda bash - Hadriel - would like to present the STRAW charter proposal - 5 drafts RjS - a conversation would be useful, had it been on the agenda I would have prepared differently. If there's confusion on deadlines, let's fix it. If we have time - let's have a tutorial on STRAW ======================================================================== 13:10-13:50 Alan Johnston Remote Call/Device Control Proposed charter Applications want to influence SIP user agents, maybe colocated or not, for call or device control. look at forming wg Get consensus on what call control and device control operations are. = Use cases = == Loosely coupled devices. == Multiple UAs with different capabilities controlled by a user. User wants to coordinate. == Proxy applications == Proxy as in remote. App (like contact center) interacts with UA and helps with call and device control. John stowe - The second one sounds like megaco to me. Alan - I don't think it's the same think Matthew Coffman - I see the same thing. ?? - what's a trusted network element that doesn't mean master. Alan - will do it on list. = Refer = Does call control. Solves a subset of use cases. = examples of call control and sip control = = Possible solutions = wg will assess the various ones = Purpose = What's call control, device control Look at model and scope what set of actions Matthew - comment on the overlap of this and BLISS? Seems like there's a lot of overlap. I don't mind the overlap. ALan - might have been done in bliss if it had been going full steam = Charter = Was sent to list. Is there interest? Will this be successful? Looking for feedback. John - feel more comfortable chartering this if sip is selected beforehand. You could be looking at every protocol to solve the problem. I'm uncomfortable using sip for device control. Is the scope to narrow or broad? Paul K - I share concerns about the scope, but don't know where to draw the line. Adam - I share concern about SIP for device control. It's not the charter's place to constrain the scope, let the wg discuss that. Jon Petersen - can recharter. Same questions are being asked in rtcweb. There are security issues. Can't solve this in dispatch. Mary - can you propose rewording? Jon - I propose non-sip method, if the group supports sip, then you win. ??? It's very broad and a large amount of work. Hadriel - get a mail list to discuss what's call control and device control. Don't need approval for that. Cullen - it's complicated enough that we haven't seen consensus on a maill list, that's why we're discussing. ??? - The charter needs to well defined. Paul - security needs to be on the charter and this effects device control. Jon - the distinction between the two use cases is a security one. Not sure what to capture in the charter on this. How well does REFER do this? Alan - several devices registering for AOR. Jon - the devices have to trust the registrar, not well defined. Mary - Are you ok with charter if security is part of the solution Paul - charter doesn't say "define the mechanism", don't see anything to remove. Cullen - wg would have to recharter to select the mechanism. Jon - define device control and call control, look at the use cases. Look at the security considerations. It will shed light on this. Charter the first questions - What is call control, What is device control? Mary - do you think IESG would approve such a wg? Gonzalo - focus on the right thing and the useful thing. Hadriel - you don't need a wg to answer quesion. Alan - it needs to have a consensus. Hadriel - are people are willing to work on this? ?? - calls have state, call control has to handle state. How does a non-sip solution handle state? alan - you do have to deal with mapping. Paul - Add defining a model and defining scope to the charter. Mary - take a hum: who wants to move forward on original charter with security added. (not many hums) Who is interested in solving this problem, independent of hum? 15 hands. ?? - Let's give this wg a chance or just stop it. Jon - I want to see the revised full charter before humming for it. Mary - will you write the text. Jan - yes. ?? - agree with adding authorization Support a charter for wg to define call control, device control, model, scope, security workings. Mary - calling a weak consensus for going forward. ??? calls for a hum on wanting more information. A hum wasn't taken, considered a count of 1. Mary - Let's modify the charter, put it out on the mail ist, but not bring it back to the meeting. Cullen - who is willing to author? Count: 2 Cullen - who is willing to follow the mailing list? Count: 9 ======================================================================== 13:50-14:30 Kumiko Ono Mechanism for referencing and verifying user attributes in SIP and email Related document: draft-ono-dispatch-attribute-validation To help identify "good" requests from unknown or privacy-blocked recipient. = Service Architecture = Caller contacts a Attribute Validation Server. Attribute Validation Server creates attribute reference ID (ARID) upon UA request. The UA sends it in the request. The receiver can query the AVS and determine whether to accept the call. Could also use a SAML or Attribute Authority instead of ARID. There are trade-offs for both ARID and SIP-SAML. Is the lack of binding of user attributes and the user identity a problem? pros - easy deployment, privacy-aware cons - weaker security. Threat of forwarding attacks and impersonation. No individual accountability. However, people care about affiliation not necessarily identity (eg, calling from a bank) Requirements and a SAML solution was discussed but no apparent deployment. Any interest in this? Jon - Yes. The decision to decouple from caller-id makes it unsafe even in moderate security environments. You shouldn't have to expose your identity but it needs to be bound to a user action. ?? - I have similar concerns. Bind the token to something - identity or IP address. Ono - Is limiting the lifetime of the ARID not enough. Jon - when you send an invite, you don't know if/when it will be deferenced. How many people might need it? Ono - there are tradeoffs, but if you limit it to 10 minutes, it can mitigate the damage. Hardie - lemonade wg did something similar. There are problems with B2BUAs that want to consume the token and provide another down the line. Make it limited rather than one-time use and shorten it. Belay is a web-based attributed-based authentication. Posted URL to the chat room. ?? - How does it scale with the AVS, you have to contact for every call. Ono - (?? missed) Cullen - not chartering yet, checking for interest? (usual identity crowd) Mary - end of the offical wg, Hadriel will present STRAW in an informal meeting. Note Well does apply. <--- end of meeting ---> ======================================================================== 14:30-15:00 Hadriel Kaplan STRAW (aka BEHAVE for B2BUAs) Proposed charter Related document: draft-kaplan-dispatch-b2bua-taxonomy Some things don't work well across B2BUA Lennox - what do you mean by B2BUA? Hadriel - my opinion - it's a UAS to UAC What must a B2BUA do to make a specific mechanism work? (like max-forwards rules) Deliverables have been posted to the mail list. ??? - it's looking at things that are already broken, not looking at how to define proper behavior going forward. Hadriel - A herculean task. Hadriel - future RFCs should have a section telling B2BUA implementors how it should work. Paul - is the list exhaustive. Hadriel - no. ?? - how do you want to charter? what's the scope? Hadriel - It won't be an exhaustive. (missed) Cullen - deliverables are not part of the charter. Can specify milestones. Can you get consensus on an unknown SIP header? Hadriel - No. Hadriel - any interest in this? Not taking a hum. (note taker has to leave)