Minutes: STIR at IETF 88 Summary: We had a good discussion refining our understanding of requirements. We were pressed for time, and did not complete the agenda for our second session. Notable elements from the discussion: * A discussion of the problems related to call-forwarding will be added to the problem statement; * Discussion of applications like ViPR, iMessage, etc. will remain in the problem statement, but the text will be adjusted to reflect list discussion; * When discussing a more refined definition of in-band and out-of-band, there was a preference in the room for defining in-band to mean within the control protocol that sets up the media; * There is a preference to limit the number of bytes the solution adds to in-band messages, but no strong agreement on what that limit should be; * There was strong consensus to include an extension point in the solution to allow optional assertions to be made about other signaling elements; and * There was desire to support both delegation from above and proof of possession as enrollment models. We had two notetakers at each session. Session one: Shida Shubert and Jean Mahoney Session two: Dean Willis and Jean Mahoney Their notes appear below: ======================================================================== Session One: Notetaker: Jean Mahoney IETF-88 stir Tuesday, 5 November 2013: 1300-1400, Regency D ======================================================================== 10m Chairs/Administrivia Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-stir-0.pptx Jabber Scribe - Dan York Jabber logs: Session One: http://www.ietf.org/jabber/logs/stir/2013-11-06.html Session Two: http://www.ietf.org/jabber/logs/stir/2013-11-07.html Note takers - Jean Mahoney and Shida Schubert Note well presented. Agenda presented. Robert Sparks asked Hadriel Kaplan about the status of the wiki version of draft-kaplan-stir-fried for the working group. It is still under development. ======================================================================== 20m Problem statement - Jon Peterson http://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement/ Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-stir-1.pptx Jon Peterson presented slides 1-7. Jon and Hadriel discussed the problem with call forwarding, which is legitimate and needs to be supported but allows ends to become malicious middles. ACTION: Add text to draft-ietf-stir-problem-statement discussing the call forwarding problem. slide - VIPR and iMessage No one on the room had issues with updating the draft with Andrew Allen's and Jon's updates. ACTION: Jon to incorporate Andrew Allen's text and Jon's followup into draft-ietf-stir-problem-statement. There was a discussion about whether VIPR should be referenced in the document. Although Martin Dolly and Hadriel didn't want much or any text referencing VIPR, since it may cause confusion, in the end the room decided that the text could stay. ACTION: Do not remove VIPR text from the draft. slide - Distinctions, distinctions Jon's tentative proposal for in-band and out-of-band definitions received pushback from Hadriel and Martin. Martin offered an alternate definition. A hum was taken on the two definitions and whether the room could live with either. There was a slight preference for the in-band definition to mean the control plane protocol that sets up the media, although many didn't care. ACTION: update in-band definition to mean control protocol that sets up the media. slide - More Open Issues There was a discussion about UDP bounds. Hadriel pointed out SBCs will delete SIP headers to reduce the size of the messages and larger messages would be less likely to make it end-to-end. Hadriel also did not want to move to TCP to make STIR work. Andrew Allen said the system has to support UDP. Eric Rescola mentioned that the smallest signing algorithms are patented. Steve Kent said there were lessons to learn from TLS and IKE on caching and fragmentation. Cullen described packet loss with size and that it was not linear, but a series of plateaus. He recommended keeping below the second plateau of 8K. ======================================================================== 30m Threats - Jon Peterson http://datatracker.ietf.org/doc/draft-ietf-stir-threats/ Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-stir-1.pptx John presented slides 8-14. Robert asked who had read the draft. Many had. Of those who had not, many indicated that they would. Brian Rosen recommended not including threats against the solutions in this draft. ======================================================================== Session one: Notetaker: Shida Shubert WG : STIR Date : 2013.11.05 ******************************** 1). Agenda Bash - No ojbections. ******************************** 2). Problem Statement Presented by : Jon Peterson Slide : http://www.ietf.org/proceedings/88/slides/slides-88-stir-1.pptx Draft : draft-ietf-stir-problem-statement-00.txt * Text surrounding call forwarding - Can't distinguish legitimate and non-legitimate Call forwarding. (Hadriel Kaplan) We need to support call-forwarding BUT it breaks the solution.. - While admitting the problem exists we need to solve what we can. (Cullen Jennings) Conclusion / Action Item: Will add some text about the call-forwarding. (Jon Peterson) * Text surrounding ViPR / iMessage - The utltimate problem of solving what the target is, is difficult - Don't want to dwell into these iMessage/ViPR discussions. (Eric Rescola) - Not meant to propose any solutions, just an informational reference. (Jon Peterson) - Cullen and I are trying to finish ViPR, the end-result is the statement of why we failed. - Should have a privacy section with reference to ViPR. (Martin Dolly) - Has very little to with STIR problem. (Hadriel Kaplan) - Do you want to point to any other works that remotely tried to address the problem space? (Jon Peterson) - Used the PSTN, there is bunch of specs in ITU-T. (Hadriel Kaplan) - Feels like advertising ViPR. (Hadriel Kaplan) - It wasn't trying to solve the STIR problem. (Hadriel Kaplan) - It was trying to solve the SPIT problem, it tried to solve the subset of the problem. (Cullen Jennings) - Explained how VIPR tried to use the PSTN to ascertain the origin identity. (Jon Peterson) - It's standard practice to reference what we have done in the past. (Eric Rescola) - Can't we just explain that it was a big failure.. Why take it out? (Eric Rescola) - Because people who don't attend IETF read it, may get the wrong idea, I don't have an issue personally... (Hadriel Kaplan) Conclusion : It's fine to leave the text.. * In-band means SIP / Out-of-band means everything else - Debate over what the definition of in-band and out-of-band is. - Need something that clarifies the definitions. (Jon Peterson) - Out-of-band is signaling can't carry any definition that references the certificate/credential. (Eric Rescola) - In-band is it's in the call-control signaling, out-of-band is, it's not. (Martin Dolly) - As soon as it touches PSTN, it's an out-of-band. (Cullen Jennings) - If SIP stuff is done first and other stuff is done later, I am okay with the definition. (Brian Rosen) - By the time something is deployable, use of PSTN is going to be so miniscule that the cost/effort doesn't make sense. (Martin Dolly) - Oppose to the definition you have.. Any call-control-signaling is in-band.. (Hadriel Kaplan) - Hesitant to decouple it too much from SIP. (Jon Peterson) - It's always good to constraint the first work to do. (Brian Rosen) - I think we should take the Martin's definition. (Martin Dolly) HUM: 1. In the control protocol that sets up the media. 2. In SIP. 3. Don't care? Observation : Slightly more hum for 1. * How much message overhead are we willing to tolerate - Is add under 1K reasonable? (Cullen Jennings) - This allows us to eliminate some potential solution. (Cullen Jennings) - Agreed, this will limit some type of solution. (Hadriel Kaplan) - I think we need to keep it lower than 1K. (Hadriel Kaplan) - It rules out of carrying the credential itself. (Jon Peterson) - I thought it was ruled out a month ago. (Hadriel Kaplan) - Minimum size for keying material is 700K, with mata-data etc it's over 1K. (Eric Rescola) - System needs to be updated anyway to support this, so it will be fine if the system needs to support TCP. (Andrew Allen) - In order for the header to be kept when going through SBC, I suggested the smaller bytes. It wasn't about the problem with FW or NATs.. (Hadriel Kaplan) - Regarding the transport, this will not be a big enough feature for the carriers to move to TCP. I don't want that to be the barrier to have this deployed.. (Hadriel Kaplan) Conclusion : No clear consensus.. Limit needs to be set seems to be a consensus among the people at the mic. ******************************** 3). Threat document Slide : http://www.ietf.org/proceedings/88/slides/slides-88-stir-1.pptx Draft : draft-ietf-stir-threats-00.txt Issue : Should it include threats against the solution? - Don't do it in this draft. (Brian Rosen) * Regarding MitM - We can't protect against MiTM because we have valid intermedaries and we can't distinguish good one from another. (Hadriel Kaplan) - We will have the discussion about how we can extend the protocol to do this tomorrow. (Jon Peterson) Time's up. ======================================================================== Session two: Notetaker: Jean Mahoney IETF-88 stir Wednesday, 6 November 2013, 1550-1720, Georgia B ======================================================================== 5m Administrivia Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-stir-0.pptx Jabber scribe: Ben Campbell Jabber logs: Session One: http://www.ietf.org/jabber/logs/stir/2013-11-06.html Session Two: http://www.ietf.org/jabber/logs/stir/2013-11-07.html Note takers: Jean Mahoney and Dean Willis Note well presented. Agenda bashing - No changes to the agenda. ======================================================================== 25m Constraints on signature construction and validation: Jon Peterson - what fields are included in the signature? - should that list be configurable? Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-stir-2.pptx Cullen Jennings presented. Martin Dolly pointed out that the To header is changed in toll-free calls. Jon said that there would be use cases where this would not work. Hadriel Kaplan thought that this would break across domains most of the time because header fields are modified. And since it would break, it would not be deployed. Martin Dolly believed it would cause interoperability issues. Cullen said that this was an extensibility option. Dave Crocker said that this mechanism was almost a copy of DKIM but not quite. Cullen said that DKIM allowed flexibility for the sender but not the recipient. Jon said that DKIM and 4474 had different actors. Jon Peterson said that this was the only story that we have for encryption. Robert Sparks took a hum on including a tool to make assertions extensible. There were hums in the room, and no one was opposed. There was a discussion about whether the From header should be used. [Name not captured] said that mobile operators toss the From header and use PAI or PPI. Cullen and Jon said that was against RFCs. Martin said that in the United States, the FCC would just put something out for comment on whether the From should be signed. Martin didn't think it would be deployed if the FCC insisted that the From be signed. Eric Rescola wanted a statement about behavior when a From corresponds to a signature and behavior when it doesn't. Hadriel wanted this to work like Caller ID. Brian Rosen wanted some text about verifying enterprises that don't have E.164 equivalence. Eric Burger wanted to know if anyone had implemented RFC 4474. Jon said that they had created test implementations. =========================================================================== 40m Credential Acquisition: Jon Peterson and Hadriel Kaplan - how can signers and verifiers obtain the appropriate credentials? - what does a verifier need to access credentials (a number, a number range, some other hint)? - is access to the credentials public or private? - are credentials associated with a single number, a range, or an arbitrary set? Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-stir-3.pptx Jon Peterson presented. Martin did not think that 'proof of possession' could be deployed earlier than carrier delegation. Cullen agreed that was the case for black phones, but companies like Google could roll out 'proof of possession' within two weeks. Cullen thought that both 'proof of possession' and delegation were needed. Jon thought that pressure in the marketplace would help carriers clarify how they want to position themselves with regard to identity. Martin said that there were privacy implications on opening up dialer apps. Eric Rescola said that dialer apps were easy to update but there were security questions. Eric Burger suggested that we ask the FCC. Jon pushed for modularity since there will be different requirements from different nation states. Jon asked the room if there opposition againt proof of possession. There was no opposition. Leif Johanson brought up OAuth as a delegation model. Jon asked him to send the idea to the list. Hadriel said that OAuth didn't fit because you are authorizing someone else to use your identity. You may be offline, and the delegate may be using the identity for months. Brian Rosen wanted to know how delegation would be implemented. Dave Crocker pointed out that DKIM has delegation. Richard asked that Hadriel put the delegation proposal on the list. ACTION: Discuss delegation models and implementation on the list. There was discussion about credentials for ranges. It was agreed that one credential per number was not a requirement. That there needed to be flexibility to handle discontiguous blocks. [Name not captured] wondered how number portability affected credentials. Jon thought that maybe a credential with a level of indirection would be useful. Martin recommended that in addition to identifying the originating party, passing information on who authenticated the originating party. Dave mentioned that Hadriel's original DKIM proposal covered credentials for ranges. Hadriel requested more time for the working group at the London meeting. Hadriel wanted to push out the Push method for acquiring credentials. Cullen said it didn't have to be decided today. Hadriel pointed out that if the database is publicly accessible, the carrier records could not be revealed because it would reveal company sensitive information. ======================================================================== 20m Gatewaying: Hadriel Kaplan - what constraints do we have on signature construction so that the signature is likely to survive transition through other protocols (can we build something that can be passed through UUI?) Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-stir-4.ppt Hadriel Kaplan presented. Presentation was cut short due to time constraints. Brian was in favor of making it work. However, he wasn't sure what could make it through SS7. Martin didn't think it needed to be part of the base. It could be put in a user-user parameter. Martin also cautioned that the tech for PSTN gateways was developed in the 90s, and he was not sure the code could be touched. Hadriel said that SBCs could deal with this before it reached the gateway. End of meeting. ============================================================================ Session two: Notetaker: Dean Willis STIR IETF 88 Robert Sparks, Russ Housley Chairing 1550, 20131106, Vancouver BC Hyatt, Georgia B (Session 2) Note Well presented Agenda accepted as previously published Topic: STIR Signaling, Cullen Jennings Slides presented First principles (separation of signaling and enrollment) agreed by room. Issue: Signature Fields Martin Dolly notes that issue with To signing includes 800-number translation problem. John Peterson noted that all the high-level translation cases that affect To are quite probably in breach of the protocol. There may be no easy answer. Issue: Additional Protection Question: Is it the sender, or the recipient that verifies the signature? - Recipient, who also needs the credentials. Question: What happens when the Identity-Reliance header in the signature mismatches with the received call? What does it mean if it ALWAYS mismatches? - The service provider verifier has the option on what they want to check wrt I-R header. Hadriel suspects it will seldom survive intact in production so why bother? It might be a waste of time. Paul Kyzivat notes that this mechanism will work in some cases, so it can be used where needed. Hadriel continues to worry that this will create an obstacle for baseline deployment. Question: What does this protect against? - A call apparently comes from one person, and is really from another. But isn't that the base function? - Yes, this is an extensibility point. Question: Since this is like DKIM, why did we break the fields out differently? Everything in DKIM is in the DKIM signature itself. — It seems harder to for the receiver to match the fields. But there are DKIM libraries that could be re-used, if they matched. Noted that its this way for matching to RFC 4474. John Peterson also noted that R-I could be used for verifying keying material, when media keying material is included in signaling, and that its the only story for such verification. Martin Dolly suggests that we need extensibility, but putting something in here thats going to get dropped is going to make for failures. Alternative: We could include the DTLS-SRTP fingerprint and other fields ALWAYS in the signature set if they are present in the request. Poll of the room: (loosely phrased) Do we want a point of extensibility that will optionally protect other signaling elements by linking them to identity? Major consensus. Issue: Canonicalization Question: Where should the source of identity be encoded? From, PAI, elsewhere? Noted that PAI may be suppressed in transit and not presented to end user. Noted that proposed rules treat number@domain identities differently from user@domain. Noted that some carriers do it differently. Question: How do we canonicalize? Eventually, the FCC is going to put out something for comment. Noted that what is being proposed here will not align with what is likely to be proposed to FCC by telephone carriers. Proposed that we do roughly what we did with ENUM. EKR notes this is all broken. Two possibilities ;either the From matches the signature, or it doesnt. We could move the verifier problem from the signaling to the lookup function. Martin notes that for calls originating from enterprises, the number typically gets majorly modified. But Hadriel notes that the fact that caller-ID gets delivered today is proof that the information is in there somewhere. Keith asks: In an enterprise, which number are you verifying? The lead? The DID? The extension? Brian Rosen notes that we will need some story for enterprises that do not have E.164 equivalents. Issue: Should STIR replace RFC 4474? - Proposed yes. Question: Does anybody implement RFC 4474 and care? - Probably not... Topic: Requirements Discussion, Jon Peterson Slides presented Issue: Enrollment, How do signers get credentials (two alternatives discussed, delegation vs proof of possession) Suggested that this isnt a first-tier problem. Jon answers that there are two potential credential systems under consideration. Selection between proposed alternatives will drive that choice. Noted that different carriers have conflicting positions here. Proposed that dialer application will be carrier driven. Eric Burger notes that the FCC is going to drive this, so we should just ask them what they want. Jon believes that different regulators will insist on each. Eric Rescorla notes that some phones have HTML5 dialers. Issue: Delegation Requirements Martin Dolly suggests that there are two major categories of temporary delegation; carrier knows, carrier doesnt know that is, delegation outside of carrier authority. There are also cross-carrier cases. Noted that we already have a very good delegation model in DNS, and that the doctors office model doesnt fit in there. Brian reminds us of the issues from PERPASS. How is this going to get implemented and used? We need to make it not a nightmare. Hadriel reports having looked at OAUTH for this a while back, and it didn't fit. Dave Crocker noted that the issue of delegation and the variety of ways in which people do delegation also has an along in DKIM. Its easy in DKIM because domain names are hierarchically scoped. Point is, theres an established base of experience and we should think about using it. Issue: Req: Credentials for Ranges Proposal that we dont have one one credential per each number; need some sort of aggregation system. Question: What is the question that the IETF needs to address? We need to explore how we deal with number ranges and aggregations of credentials. Suggested by Martin Dolly that neither extreme makes sense. Noted by Chris that it should be flexible; different sections of number allocations might need different key rotation policies, but having large ranges of numbers tied to a single key is not a problem. Question about number portability: this tends to break up ranges. A lot. This will lead to a need for real-time validation of credential scope. Test by ludicrous delegation proposed by RJS. Would we get things like delegating even numbers to A, odd numbers to B? Or should we restrict ourselves to disjoint sets of contiguous numbers? The latter seems to be preferred. Martin Dolly notes that typically a service provider will typically have a bunch of different certificates, and that there may be a back link to who did the authentication. Noted by Dan, a reseller, that they get completely discontiguous assignments, and dont want to have to track a credential each. Dave Crocker reminds us of the DKIM selector expression; an attribute under the name. We should look at this again. Noted by Chris that this illustrates the beauty of the domain name system. Issue: Expiry, Revocation, and Rollover No debate. Issue: Signer Provisioning No debate. Issue: Verifier Credential Acquisition Note to give Hadriel extra time in London. Push-vs-pull discussion deferred. Issue: Which credentials do verifiers need? Some debate, no conclusion. Issue: Public or Confidential database Some debate, no conclusion. Could always query the PSTN ... Topic: STIR In-Band Signature Transport, Hadriel Kaplan Slides presented (no time for all of the slides) Issue: Do we want anything besides SIP, like XMPP, SS7, H.323, etc. Noted that out of band is also a choice. Brian Rosen speaks in favor of making it work. Comes down to what can get through the SS7 network. Martin Dolly doesnt think it needs to be part of the base. Touching the gateway code base is really hard. But we could do it in SBCs ... ========================================================================