# STIR Working Group at IETF 115 ## Executive summary * draft-ietf-stir-identity-header-errors-handling, draft-ietf-stir-messaging, and draft-ietf-stir-passport-rcd were discussed. No changes were identified. All three are on the December 1 IESG Telechat agenda. * The chairs will issue WGLC on draft-ietf-stir-servprovider-oob * There were major revisions to the mechanisms in draft-ietf-stir-rfc4916-update-01 (Connected Identity for STIR). The participants in the room had consensus to proceed in the direction of the changes. There was no interest in pursuing a fix to "from-change" in this document. * Discussion continues on using OSCP and OSCP stapling. ## Administrivia - Agenda Bashing - Minute Taker - Jabber Scribe - Bluesheets ## PASSporT Extension for Rich Call Data - draft-ietf-stir-passport-rcd-22 - Have all IETF Last Call issues been resolved? - Chris Wendt presenting Ben Campbell: There was a comment in the ArtArt review that the "rcdi" claim should include a syntactical indicator that a field contains a URL. We are not taking action on that, correct? Chris Wendt: No we aren't, but it's been clarified. Jon Peterson: It's been sticky in RCD for a long time, I don't feel we got closure on the threat model, but I think it's too complicated for anyone to ever use it. ## Identity Header Error Handling - draft-ietf-stir-identity-header-errors-handling-05 - Have all ART AD Review issues been resolved? - Chris Wendt presenting No questions. ## STIR for Messaging - draft-ietf-stir-messaging-05 - Have all ART AD Review issues been resolved? - Jon Peterson presenting Jon: Nothing interesting, waiting for missing directorate reviews. ## Connected Identity for STIR - draft-ietf-stir-rfc4916-update-01 - Major revision; is the WG comfortable with it? - Jon Peterson presenting Jonathan Rosenberg: On the mechanism change, I don't think backward compatible support with RFC 4916 is important. I think this is going to work, I would remove all the cruft, including the "from-change" option tag. Jon Peterson: I'm going to make the case for "from-change" in a minute. Jonathan Rosenberg: It's not clear what you should do when it doesn't match, it's not going to work in many situations. Jon Peterson: I suggest that we establish a criticality mechanism where the user can specify when it must match for the call. Jonathan Rosenberg: Even in banking cases, this isn't going to work all the time, I'm not convinced this is going to fix the problem. Jon Peterson: It will tell when everything worked, allowing more checks if it does not match. Jonathan Lennox: If I try to call Cullen, but get assurance that I got Jonathon, what use is that? Jon Peterson: You get assurance that Cullen redirected the call. Chris Wendt: The cleanup is good and was needed. This puts us in a good position for messaging. Ben Campbell: Some US carriers use UDP, and they still have fragmentation problems. However, I don't think we should worry about that. Cullen Jennings: I think that in the vast majority of cases where I care about this working, it will work. For example, the bank calling me. Jon Peterson: It will work because most of this is SBCs. Jonathan Rosenberg: This isn't going to work for banks that use TFA. They will want other identity checks. Jon Peterson: Do we want to fix the RFC 4916 mechanism for "from-change" in this document? Poll results: 0 raise hands, 6 not raised, bunch of abstains. Conclusion: Leave it to another document, do not delay this document. Chris Wendt: Is it relavant for the security use case considering PAI? Cullen Jennings: Is there anyone we might be able to rope into the formal analysis of the security properties of this? Jon Peterson: I would like that. Ben Campbell: From a chair's perspective, this is a big change. I've not heard that we need to go through the adoption process again for this, does anyone disagree? (No-one disagreed.) Conclusion: No need for a new adoption call; proceed with this document. ## Out-of-Band STIR for Service Providers - draft-ietf-stir-servprovider-oob-03 - Is this ready for WG Last Call? - Jon Peterson presenting Ben Campbell: ATIS has been building heavily on this for getting around non-IP interconnects. Jon Peterson: The ATIS use-case is primarily concerned about there being an IP-NNI plus some satellites, so building an adapter for those. There would be a national federation of Call Placement Services (CPSes) that broadcast the PASSporTs between themselves. There are privacy implications that we can't accept in the IETF. The I-D recommends using STIR credentials to authenticate participants, there is a very different model in ATIS focused on these "gateway" cases. This is focused on coupling the CPSes with carrier operations to mitigate the security and privacy issues. Jon Peterson: Can we ship this document as is? Chris Wendt: I agree. I think how this gets implemented in networks is different to the document, but the constructs are there. Agree that this res ready for WG Last Call. Ben Campbell: The WG Chairs will issue WG Last Call for this document soon. ## OCSP Usage for Secure Telephone Identity Certificates & OCSP Stapling for Secure Telephone Identity - draft-ietf-stir-certificates-ocsp-03 - draft-peterson-stir-ocsp-staple-00 - Stapling is now allowed; any concerns? - Jon Peterson presenting Richard Barnes: In the Web PKI mechanism the CA does not push the OCSP Response; the certificate holder pulls it. Chris Wendt: I think CAs have been very closely integrated with the AS. I don't think we should have a fragmented solution. Let's go straight to staples. Richard Barnes: Even if you don't get an round trip time (RTT) benfit for stapled OCSP, you still get a priavcy benefit. Jonathon Rosenberg: Most of the time you already have an RTT to the signer, so you might not need to pay the RTT twice. Could you do something with bloom filters? Jon Peterson: Maybe, I've been talking about this with others. Chris Wendt: Do we need both CRLs and OCSP? Jon Peterson: In my opinion this is a replacement for TN-by-ref. Russ: To clarify, if you get a no in the OCSP response, that doesn't mean the certificate has been revoked. In this case, it means that the certificate doen not cover the telephone number (TN). Chris Wendt: Could we just have some form of stapling and not OCSP? I'm worried about fragmentation. Jack Rickard: Are we worried about with remote OCSP, someone just trying to get an OCSP Response for each TN number in turn? Jon Peterson: I'm on the fence about this, I could be persuaded either way. Jon Peterson: Would people be okay with the size increase? Subir Das: What if the telphone number isn't exactly correct? Jon Peterson: All you're looking at is the "orig", which never changes. A new PASSporT is needed of the "orig" changes. Jonathan Rosenberg: Less is more, just do stapling. Jon Peterson: Should I recombine these again then? Jack Rickard: This begins to look a lot like short-lived certificates. Ben Campbell: It depends whether you regenerate a key. Jon Peterson: There are small computation tradeoffs here. Jon Peterson: Since we haven't seen uptake of ACME, I'm worried about the uptake of short-lived certificates. ## Any Other Business (if time permits) Ran out of time.