Session 1: Tuesday, November 8, 1300-1500 

as reported by Sp[encer Dawkins

Notes:      Eric Burger

                Spencer Dawkins <spencer@mcsr-labs.org>

Chairs Agenda Bash  

• No obvious bashing (except that we may talk about GRUU in both sessions, because Dean ain't leaving without GRUU)
• Is location conveyance really on the agenda? We'll talk about this offline

Chairs Status, Charter and Schedule 

• We have a new charter, please review
• New constraint - standards track extensions and new features must be generally applicable -Don't explore the use of SIP for specific environments and applications
• Have dealt with Identity, but not Response Identity
• End-to-Middle is now ready for IESG
• Guidelines for use of existing security mechanisms such as TLS, IPsec, certificates
• Draft standard versions of SIP and critical supporting specifications (because Newtrk is going to make this easier, right?) Current normative dependency rules make this impossible
• Jonathan - this is a process issue - not trivial, took four months to do 3261 as PS. WG hasn't discussed this at all, how did this happen?
• Robert - next generation spec is palatable, draft standard is not. We have too many bugs to do this in one jump
• Dean - deliverable came in during IESG deliberation - where is the AD? Not in the room (but Allison came in immediately after this, see below)
• Jon doesn't remember this discussion, but Allison is the responsible AD
• Jon - all of normative dependencies have to be same-or-higher in order for 3261 to advance - and very few 3261 references have been advanced to draft
• Scott Lawrence - in theory, multiple interoperable implementations of each MUST in the spec. HTTP was an 8 month effort for 6 of us, SIP has more.
• Robert will continue to hold the token for this documentation
• Allison - may eliminate Draft Standard document category anyway, so... Need a document on critical supporting specifications - that's what the milestone is. Since we don't have ISDs yet...
• Jonathan - have an uncompleted draft of a spec to list the critical supporting specifications
• Rohan - we have an action item to clarify this milestone...
• We have published no RFCs since IETF 63, and we have a lot of documents in the queue - please watch for Auth-48 (which is 48 HOURS, not 48 DAYS)...
• Identity is mostly good, we've broken out a separate status code, that's all.
• MIB is in expert review, the step before last call. Please don't take a long time to address comments from MIB doctor, because that makes re-review take longer.
• We have a boatload (that was the unit of measure) in WGLC or ready for WGLC.
• Redoing the supplemental web page to drop off what new tools do automatically
• Cert draft is moving from SIPPING to SIP. Who will implement this? Seven implementers in the room, we will pick two implementers as reviewers (but others please read it as well).

Chairs (announce) Response Identity draft-cao-sip-response-auth-00 

• We've gotten one response to the questions on response identity - please send replies, this is important.

John Elwell  Connected identity draft-elwell-sip-connected-identity-00 

• Draft coming from offline discussions since last IETF
• response identity may be too hard to solve. If you can't do that, maybe we can send identity the other way
• Two new headers - Connected-URI and Connected-Identity (which contains Connected-URI as part of signed fragment)
• Several alternatives considered, but they were non-starters (changing From/To, not compatible with 2543, while "do nothing" becomes INVITE/Replaces with no normative specification on fate of existing dialog, works only for for INITE-initiated dialogs, doesn't work for early dialogs, and has more messages).
• Which of three options should we use, going forward?
• Rohan - would like to support "two headers", it's really hard to figure out that someone is doing something wrong in the middle of the network, and objections to "two headers" are mostly philosophical.
• Cullen - 3 and a half years since 3261, five years before this happens. Most proxies will support 3261 by then, anyway. Too many identities that get handled incorrectly in SIP now - but "do nothing" is not a plan.
• Jonathan - like "changing From/To" - how many people have products that won't work for this option? A few, but no one thinks they can't fix the problem.
• Robert - still having SIPIT problems because people changed the white space in a name - stuff isn't going to "just work"
• Jonathan - how long do we wait?
• Rohan - we just have to choose with our eyes open.
• Jon - am worried about how authentication works with new headers, as opposed to existing identities. This goes away with "changing From/To".
• Robert - would support new headers in a vacuum. Really like one place to look for identity. If we take this path, making From/To sane (which it isn't), we need to know what we're suggesting about backward compatibility. Be draconian - don't just keep fidlling to accommodate broken implementations.
• Jerri  - From/To was overloaded in 2543, it was good that we changed this in 3261.
• Dave - when DO we break backward compatibilty, if we don't do it now? Are we breaking backward compatibilty on a really desireable feature?
• Is this a new version number? No, it's in 3261.
• Jon - First identity draft says From should really contain an identity, not random cruft. Need to change From header, NOT the To header  in responses (because it's unauthenticated) - there are a lot of reasons this is broken.
• Jonathan - how important is all this?
• Jon - there's no authorization decision we're going to make based on who received the request - they've already received it.
• Cullen - identity gives body integrity, not just caller-ID. That's really important. It is nice to bind responses to who the request went to. There was no way to challenge the 200 response, but outbound draft allows this over TLS, etc. Deserves exploration.
• Jon - value of integrity begs lots of questions in retargetting draft, and I'm not sure there's a lot of value in this. Maybe this isn't as important as we are making it sound.
• Jonathan - whole point is why you trust a response from Fred to a request you sent to Bob.
• Sense of the room on going forward with changing From in mid-dialog - updates 3261 because you MAY change From - Rough consensus but not a lot of speakers on what we are choosing, so... 
• Martin - is there going to be a hum on To in responses?
• Gregory - Not sure I understand SIP stuff, but it's difficult to trust things that change in mid-flow.
• Jonathan - user on the other side of PSTN gateway, doing a call transfer - that's the use case for this.
• Hesham - concerned about effect on hash in Identity header. Can we do an option tag for this?
• Jonathan - this is not an UPDATE, it's an EXTENSION
• Jon - am concerned about To headers in reponses - in dialog-forming responses? Yes, and that's what Jon has heartburn over.
• Cullen - we discussed this stuff before we had an authentication mechanism. We need to write some stuff up. We need an Internet Draft that explains how this would work before the group - we don't have a definition of what a changed To header in a response means, in any specification
• All in favor of investigating - we will be invesigating and writing drafts 

Jon Peterson  SAML draft-tschofenig-sip-saml-04 

• We have a chartered milestone for SAML with SIP - is this document it?
• Jonathan - the draft doesn't say how this actually works, it's vague, open issues... don't adopt until it says more
• Question of how you get SAML into SIP isn't the same as who populates SAML in SIP
• Current proposal is for SAML-Assertion header, but it's totally undefined in the document
• Cullen - cannot figure out how to use this for anything - document is at an early stage. Lots of assertions might get stuck in a message, how to figure out which artifact is interesting to you? End-to-middle draft has the same issue. SAML's a framework, we still have a ton of work to do. How many assertions can you stick in a message, about roles, etc.
• Jon - SAML has its own internal way of figuring out what assertion to stick in based on communities, etc.
• Jason - How does an assertion get bound to a specific message?
• Jon - AID can be inspected by anyone.
• Jonathan - this is NOT "obvious" - it was a total surprise to me!
• Don't have consensus to adopt at this time.

Dean Willis   Answer and Alert Modes draft-willis-sip-answeralert-01 

• Yes, OMA Push-to-talk Over Cellular needs this, but we're not getting much in the way of comments, so we're not taking OMA's wishes seriously.
• Completely rewrote Security Considerations after talking to Cullen.
• Cullen - if policy says "don't do it", the output is, "don't do it". So what? "Whoopie cushion" attack is a lot easier than "bug my office" attack - is that enough? Test calls would be fine, but draft isn't explicit enough
• Robert - complained about lack of feedback, is this because no one cares or because no one agrees
• Cullen - I want the "bug my office" version to just go away
• Want Dean to go away and finish it? A fair number of hums do.
• Cullen and Robert both have a pile of red comments on this draft
• Andrew - OMA doesn't actually want "bug my office", so please fix this.
• Jonathan - SAML role called "operator", you authorize based on SAML roles?
• Paul - it's not in the draft as "bug my office", it's "baby monitor". With proper authorization, this stuff is OK.
• Can we use the standardized use of "alert-info" from SIPPING? We'd pull out a whole bunch of text if we did
• Andrew - don't need Alert-Mode header in OMA, so that could go. Need to work out syntax as soon as possible - OMA is interoperability-testing products based on current syntax now
• Paul - Alert-info is much better solution

Kumiko Ono  Trust Path Discovery draft-ono-trust-path-discovery-01 

• Draft may be of interest to SIP
• Want to protect against unsolicited bulk messages, based on reputation of that stranger
• How to get stranger's reputation? third-party or trusted friends?
• How to gather trust paths? generate, exchange, aggregate to multi-hops
• Proposal is for push-based trust path model
• Cullen - we get to about a million friends-of-friends in very few hops
• Henning - scaling is an issue - this is done institutionally (sounds like pull-based to a push-based repository)
• Jon - great work, please keep going, keep keying off presence. Had been leaning toward pull-based model based on privacy and scaling. Information is dynamic - don't have to query for introductions very often. Know there is research about zero-knowledge mechanisms that also seem attractive. What were pull-based model problems? 
• Kimiko - first call is in real time, and pull-based model was slower in real time
• Henning - want to find out who else trusts random caller. This is an unsolvable problem but you may trust your friends' judgement that bounds the scalability and latency concerns
• Jon - real-time definitely introduces a constraint, but it's on the answerer's side - phone could ring a couple of times before you finish the messaging, and that could be OK
• Igor - DKIM has same problem, why not the same answer?
• <AOL> - spam problems are bigger than you think. AOL can't compute this for three degrees in-house. Push-based argues for domain-based database
• Jonathan - IAB messaging workshop report (a year ago) recommended distributed reputation system investigation
• Rohan - please keep the mailing list advised, but probably won't be doing more agenda time in SIP.
• Jonathan - this is BOF-worthy

David Schwartz SAML for SPIT draft-schwartz-sipping-spit-saml-00 

• Have a deployed peer-to-peer network behind this work
• Draft relies on SIP Identity Framework and SAML
• Henning - more useful to look at how easy it is to get ANOTHER identity - that's why blacklists work
• Cullen - I like the draft, SPIT is stopped by a lot of techniques, this helps. What about reputations of service providers, or other parties making assertions?
• Jon - has a domain focus. Could this be broadened to apply to an end-user device?
• David - end user devices don't support SAML right now, but this would be possible if they did.
• Jon - federations and islands? We'd like this to be end-to-end as possible
• David - we're working with what's out there today

Rohan Mahy Remote Call Control draft-mahy-sip-remote-cc-02 

• Draft resurrected with more narrow focus, it's smaller - remote answer, remote reject
• Small addition to stuff you can do already do.
• Uses Target-Dialog header to solve main problem - select context/session/dialog
• Clarifies authorization rules
• Draft needs a lot of work  - "Drafting While Intoxicated"
• Needs examples, normative text to use Target-Dialog
• Kishore - like this draft - does not address arbitration - not just call state, but endpoint state, is this in scope?
• Rohan - not thinking about this yet
• Francois - like this, it's time to think about this seriously
• Paul - REFER is black magic in general. How does this interact with REFER?
• Rohan - new document or addition to documents?
• Paul - feels like 3261 is missing something
• Jonathan - headed toward full CTI support
• Show of hands for SIP interest - a couple of dozen interested.