Minutes: Secure Telephone Identity Revisited (STIR) - IETF94 Summary: The attendees approved of the design team's suggestion to shift the syntax for carrying the signature to use JWT as captured in draft-ietf-stir-rfc4474bis-06. Discussion converged on not explicitly signaling whether where the number was taken from (PAI or elsewhere) and on including Date in the signature. The attendees supported having multiple signatures, but expressed concern that each signature have enough information attached to be semantically distinct (spec). Extensibility, and policies around standardizing extensions will continue to be discussed on the list. The next steps will be to revise rfc4474bis, splitting the the token description out into a separate draft. We expect these drafts by the end of November, and we expect to be able to WGLC these drafts. The group discussed the requirements for the credentials, and began working towards some technical decisions. We expect a design team to form and report recommendations (likely mid-December) after the revised rfc4474bis and new token draft are available. The full notes are below: ============================================================================== STIR: IETF 94: Monday 1300-1500 --------------------------------------------------------- 10m Administrivia Presenters: Chairs Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-0.pdf Jabber scribe: Daniel Burnett (1st hour), Cullen Jennings Jabber log: http://www.ietf.org/jabber/logs/stir/2015-11-02.html Note takers: Jean Mahoney, Steve Donovan Note well and agenda were presented. No changes to the agenda. --------------------------------------------------------- 20m Report from design team discussions Presenter: Sean Turner Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-1.pdf No comments or questions were raised. --------------------------------------------------------- 30m draft-ietf-stir-rfc4474bis Presenter: Jon Peterson Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-3.pdf On the question raised on Slide 4 - The Bare Minimum: Is there a need for a “switch” to signify using PAI? Jon pointed out that currently there is no such thing, but it has been working since PAI was first introduced. Chris Wendt agreed in general that it works as-is, and it would be simpler to keep the logic the same. Richard Barnes raised a concern about having to verify every PAI in every combo. Dave Crocker said that the validator wouldn't know which choice was made by the signer. Jon asked for more eyes on the draft. Cullen pointed out that the From and PAI carry the same information. He was also fine with leaving as-is. Jon raised a concern about the modification by SBCs of the Date header field and asked if there were any examples of such behavior. Cullen said that he had seen SBCs accidentally modifying the Date. Since Date is almost never modified, it makes a useful debugging tool. Sean Turner said that Date modification seems like a surface for an attack. Jim McEachern said that call forwarding may modify the Date. Jon said some behaviors are not compatible with an end-to-end security system, but if the Date had only been tweaked a little bit there were strategies for handling it without re-signing. slide 5: The Bare Minimum Adam asked for clarifications. Jon said that the JSON header and claims were optional since they would make the message larger and he wanted to discourage that. Jon asked the room is anyone was uncomfortable with JWT. Robert Sparks, as an individual, had no problem with it. Sean agreed with it and wanted to move on. Chris reiterated that JWT could be used for other purposes. Jon said that, although SBCs are not defined and have broad powers, we want to get through them and need to decide what will work for deployment environments that we care about. Chris said that it would be easy to update SBCs. slide 6: Multiple Identity Signatures Russ Housley from floor supported multiple identity signatures, and pointed out that email went through a transition from one to multiple signatures caused by the transition from SHA-1 to SHA-256, and that there could be text that could be reused. Jon said that "spec" parameter would allow for signing different fields for use in authorization, but we would not specify how the authorization decision is made. Jon talked about a transitive approach to security, where you don't trust the endpoint but you trust the intermediary. slide 7: Handling Metadata Richard Barnes mentioned a specification that could be used instead of separate grammars. Jon wanted a pointer to that draft. slide 8: Extensibility Size of the message was discussed, and Adam wondered what was sensitive to it. Robert pointed out that the size was still an order of magnitude lower than an SDP negotiation. Jon said that there were implementations that could not handle really large headers. Robert said that the issue had not been seen at SIPit for many years. Chris said that since UDP is used, it's valid to keep the headers as small as possible, but he didn't know if it was a showstopper. Jon asked what the appropriate IANA policy would be for this. JWT extensibility's IANA policy is expert-review with specification. He didn't see how we could be less constrained than that. Dave Crocker pointed out that DKIM's signature lists the fields it has hashed. Jon said that is what the first option offers. Adam said that JWT supports private use, but it would be nice to have the information collected somewhere. Richard pointed out that if you require the verifier to understand the field, then you get stuck in lockstep upgrades. Jon clarified that the 1st option covered adding just one or two new fields. The second option solves a different problem that may not be specified in the IETF, but the people wanting to solve that problem want to use the baseline mechanism. Jon didn't think it was ideal, but he would not say no. Pete Resnick suggested making it a FCFS registry, with an optional specification, and the IETF will use the specification. Cullen wanted to know why they did not want FCFS. Jon said that the arguments against it are that the specs should not be public, and IETF interoperability constraints don't apply. Cullen said that if those were the arguments, then "spec" should be removed. Jon said that with "spec", you don't have to include canon and make the message huge. For JWT, you have to include canon, which is why both have their place. Alissa Cooper said don't pervert it for people who don't want to do follow process. They can just do it. ACTION: Discuss IANA policy on list. slide 9: We Have the Technology Jon asked the working group if it was OK with having a separate WG item on the token that would be Proposed Standard. Sanjay said that two docs provides more flexibility. Sean and Chris were fine with it. slide 10: Next Steps Jon will revise the draft. ACTION: Sean, Chris, Richard to review updated draft. ACTION: find reviewers on list. slide 11: The job of non-SIP transports Jon pointed out this was not in charter and it needed more discussion. Adam wanted to use this in RTCweb in the future. Jon would be happy to work on it and set up a design team. slide 12: Not So SIP specific Jon asked that, if anyone had a problem, to please talk to them. --------------------------------------------------------- 60m draft-ietf-stir-certificates Presenter: Sean Turner Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-2.pdf slide 6: Ultimate Requirement Questions Jon said that the first question was a policy question. Richard said that the slide was one question in four forms. Cullen wasn't sure what to make of the questions, and that if the members of club were decided by the FCC, the IETF could only provide technology in supporting that club. Sanjay said that, on the last point, you need to be able to trace the call back. Russ from floor said that we were specifying a trust store but not what was in it, that people will populate the store differently. Richard said that it was not a technical decision. Build a scalable infrastructure to deal with it. slide 7: Transitive Trust vs Intransitive Trust Jon said that it's unclear how great the value is since we already have ways to determine if the previous hop vouched for the call. The difference is that you can see past the previous hop. Chris said that the slide is implying that the call can only go between carriers, but the call will be going through multiple hops and untrusted networks. Jon wondered what you would get with using the PAI, but Chris said no one is saying that PAI should be trusted no matter what. Jon said that last-hop security was not much better than relying on PAI. Jon asked if we should detect abuse in realtime or just in audit. ACTION: Discuss transitive vs intransitive trust on the mailing list. slide 8: Public or Confidential Credentials? Jon said that 2 years ago, there were concerns that the subject would leak information, but the right way to manage certs is antithetical to those concerns. Chris pointed out there is some risk of leaking information no matter what you do with the credentials. Sean recommended that implementations be allowed to pick their pain threshold. slide 9: Certs for OCN Jon explained that OCNs may help alleviate leakage concerns. Richard said there were tradeoffs with cert size, and that there were issues with OCSP latency. Brian Rosen said that OCN doesn't fix the problem and asked how to get the assignments to those operators that don't have OCNs. Chris wanted flexibility. slide 10: Other Transitive Approaches Jon and Chris saw some promise here, and Chris said there should be some semantics here. slide 11: So what now? Sean and Jon want a design team call on certs. Chris wanted to start out simple with carrier certs and then go from there. ACTION: Sean Turner to set up a design meeting on certs. Russ said that the syntax and semantics of the signature should be nailed down so that we know what the requirements for the cert are. Jon said that the FCC has created a timeline for this, and he wants an LC as soon as possible. ACTION: Jon to bring up Date concerns on mailing list to ensure that it is not a blocker. Robert recapped major actions: - Revise 4474bis draft between now and the end of November. - Adopt the token draft as a stir doc. - Start the LC process on 4474bis at end of November. - Hold a design team discussion in mid December on certs.