Minutes: STIR at IETF90 Tuesday July 22, 2014 Note takers: Paul Kyzivat and Shida Shubert Jabber Scribe: Jonathan Lennox Summary: Problem Statement: * The proposed text will be added in AUTH48, softening 'must prevent' RFC4474bis: * The canonicalization algorithm will drop "ABCD", but account for "#*". * The "canon" parameter will remain in the mechanism * The document will focus on dialog forming requests, but will not prevent specifying the use of the mechanism for other requests in the future. * Further discussion of REFER Baiting and credential caching is needed. * Manadatory protection of SRTP keying material will be added when that material is available. Credentails Roadmap: * The group expressed strong support for adopting draft-peterson-stir-credentials as a WG item ----------- Combined notes from Shida Shubert and Paul Kyzivat Session 2014-07-22 0900-1130: Salon B - Problem statement - The problem-statement is almost done. Just need to add one thing that had been forgotten, about preventing 3rd parties from discovering call callers and callees of a particular number. (actual text in slides). * Richard Barnes : Concern raised that, as stated, this will be impossible to meet. Should soften it. * Martin Dolly: asked for assurance that carriers are not 3rd parties for this purpose. Agreed. - RFC4744bis - Canonicalization discussion: * You are not only stripping special characters, 0 before setting the country code, dial string etc need to be stripped.(David Schwartz) * Aware.. Especially an issue with the To header.. [Jon Peterson] * Country code is not a problem because the signer knows what country code it's signing for regarding From [Cullen Jennings] * The problem is not about From but it's with the To. [Jon Peterson] * When user is calling out Internationally, then user explicitly enters the International number, don't think it's an issue [Cullen Jennings] * If the call is delivered right now by the carrier, the problem will be solved by the carrier is what I am hoping. [Jon Peterson] * Concern I have is the case where transformation happens at the termination side. [Jon Peterson] * Anybody knows where "A B C D" etc are used? [Jon Peterson] - Few hands raised. * You won't see this but they are used. [Brian Rosen] * It's used in trunk addressing. It won't cause an issue. [Martin Dolly] * Anybody know where user actually use these?[Jon Peterson] * No..(multiple respondants) * Will not consider "A B C D" as something we need to worry about. * Not human input but probably need to make sure it won't cause any issues. * "*" and "#" will only show up in To. Not in From. [Jon Peterson] * Wrong. Operator specific short code shows up in From. [Brian Rosen] * Will allow them as characters in To/From. [Jon Peterson] * Think these numbers will fail because they are converted at the intermediary.[Jon Peterson] * If we sign the short code, Cut/Paste attack will become an issue. [Jon Peterson] * These short codes change all the time, enumerating valid short code is unreasonable. [Jon Peterson] * It will create a new class of attacks. [Jon Peterson] * May be those string can't be signed. [Brian Carpenter] * Need to be careful considering the emergency call [Andrew Allen] * Probably okay to say can't sign the "#,*". [Brian Rosen] * 911 is a real number. Doesn't have any substitution number. [Brian Rosen] * Will be difficult to sign callback with 911. [Brian Rosen] * I don't see anything in req docs that mandates legacy service code. [Richard Shockey] * I am happy to get rid of "A B C D" etc., call to "911" is something we need to support.[Jon Peterson] * Let's find the service code that we need to support. Let's enumerate the list of service code. [Robert Sparks] * Short code is not legacy.. [Brian Rosen] * Any issue with the fact that it will be clear-text? [Robert Sparks] * "canon" itself is not itself covered by the signature. [Jon Peterson] * "canon" is not under signature because it may be modified by the intermediary or stripped. [Jon Peterson] * If "canon" value and To/From doesn't match termination side may not bother with the verification. [Jon Peterson] * If it's a sense of optimisation, I am okay with it. [Jonathan Lennox] * I think it's an optimisation, and if people see it this way I am happy to add this. [Jon Peterson] * Any strong objection to this? [Jon Peterson] - no objection. - Baiting Attacks * Isn't this about From? [Robert Sparks] * Looks a lot like the behaviour of B2BUA. [Jonathan Lennox] * There are worst variants. [Robert Sparks / Jon Peterson] * There is no difference between clicking a link on the web page OR using REFER. [Robert Sparks] * Because of the preloaded route sets etc, I understand. [Jon Peterson] * GW scenario gets really hairy. [Jon Peterson] * In a real world, REFER never gets back to the user, they are consumed by the network. (AH) * In a SIP Connect spec that's what happens. (AH) * REFER/Redirect will not happen between the Interconnect. Only between the subscriber and the service provider [Martin Dolly] * Some sort of the partial media protection seems to solve many of the issues. [Jon Peterson] * Need to have discussion about the actual architecture/deployment. [Jon Peterson] * Corner case is where the attack happens. [Eric Burger] * Will need to re-write SIPConnect2.0 so we can talk about this. [Richard Shockey] - Scoping issues : non-dialog forming request * Should we protect mid-dialog requests? [Jon Peterson] * Should re-charter [Eric Burger] * Many attacks that are similar to what is in scope right now.[Jon Peterson] * Why not state that the doc can be used in non-dialog forming requests but haven't explored the consequence.[Brian Rosen] * Rather not limit the scope and allow the use. [Brian Rosen] * Some of the machinery may only exists in the dialog forming requests [Paul Kyzivat] * CONCLUSION: Potentially going to go in that direction. Add note about things will probably change. Will not include it in the initial scope. [Jon Peterson] - Scoping issues : credential caching * Porting can happen in minutes, after 50mins won't be valid anymore. [Brian Rosen] * Credential will be valid even after the porting. [Jon Peterson] * If porting happens then the hash/credential will change. [Jon Peterson] * Don't think the hit-ratio will be good enough to justify this. [Brian Rosen] * May need some deployment experiments to see if it's worthwhile. [Jon Peterson] * How? [Jonathan Lennox] * URL may be the cache key. [Jon Peterson] * Just delegate to the credential mechanism. [Jonathan Lennox] * Is it appealing enough to tackle it now? Will it be harder to do it later? [Robert Sparks] * Will need to put some brain power, if slow people may turn it off. [Sean Turner] * Having an understanding of how it will actually be deployed may be something worth while before we make a hard decision. [Martin Dolly] - Scoping issues : Partial body protection * Would like to see at least the hash for keying material of SRTP when available.[Richard Barnes] * Concern with end-point signing and then intermediary stripping it. [Richard Barnes] * There is various cases where there is valid MiTM which needs to strip SRTP. Should that be a failure case? [Jonathan Lennox] * Yes it should be fail. [Jon Peterson] * What about financial case where broker and client call needs to be recorded? * Financial case is not a concern.. There are multiple way to do the recording. Either end-point replay and send it to recorder or terminate the call at the call-agent. * Complexity will become the enemy of deployment. UI will need to be worked out. [Richard Shockey] * SIP is designed to permit MiTM, so no point worrying about MiTM. [Eric Burger] * For that case where SRTP is used, it will be an optional and can be utilized by those people who use SRTP. [Jon Peterson] * Should we move this to Mandatory if SRTP is in the media? [Jon Peterson] * Concern with different way to sign the body. [Paul Kyzivat] * Will not dispense the identity-reliance.[Jon Peterson] * Getting the doc out so we can get deploy is he first priority. Want to make sure this won't delay it.[Martin Dolly] * Go without it.. Would be my preference. [Richard Shockey] - Credentials Roadmap * Will need to decide which one to pick. (cider or certificates) * Don't need one-to-one uniqueness in Cider [Martin Dolly] * Problem is when there are multiple authority for TN then we need a selector to figure out where to get the key. [Jon Peterson] * This is telephony not the Internet, and it involves national numbering plan. We can recommend an option but they will decide what they will use. [Richard Shockey] * We will keep the questions that need answers open for a bit more.. [Sean Turner] * The list of questions are fine. [Richard Shockey] * Do we know enough to pick one? [Robert Sparks] * We do have enough information to pick one at least at the IETF and should have a recommended path. [Richard Shockey] * If we could get to one, I would prefer to pick one. Looked at implementing both and it didn't give me a headache.[Brian Rosen] * If someone comes in the future, will it prevent someone to introduce something else? [Robert Sparks] * Will need to come up with text comparable to what we are going to define for one we decide on. [Jon Peterson] * I am seeing CONSENSUS that we want to work on one.. [Robert Sparks] * HUM * Certificate got very strong hum * Cider got no hum * Neither got no hum * CONCLUSION: Certificate draft will be the draft moving forward. * Email list is very quiet, please fix it. [Robert Sparks]