Minutes: Stir at IETF 89 Summary: * The problem statement document has been approved by the IESG but awaits minor editorial changes before proceeding to the RFC Editor * The threats document completed working group last call, and also awaits minor changes before proceeding to the IESG * draft-jennings-stir-rfc4474bis and draft-peterson-stir-certificates were discussed. The detailed discussion is captured below. Highlights: - Much of the discussion was about whether the results of canonicalization of a number should be literally captured on the wire, and, if so, whether that capture should be cryptograhically protected - We will issue a call for adoption for draft-jennings-stir-rfc4474bis-01 next week. * Alex Bobotek gave us an overview of M3AAWG and VTASIG activities We had two notetakers at this session - Jean Mahoney and Peter Yee. Their notes follow. - Notetaker: Jean Mahoney ----------------------------------------------- Secure Telephony Identity Revisited (STIR) IETF89 - Monday 0900 -------------------------------------------------------- 5m Administrivia (Chairs) presentation: http://tools.ietf.org/agenda/89/slides/slides-89-stir-0.pdf presenters: Russ Housley, Robert Sparks Note takers: Jean Mahoney, Peter Yee Robert Sparks presented the agenda, room didn't have any changes. Robert - There are 2 working group docs in flight - problem statement approved, needs tweaks. Threats has gone through LC - it has comments, needs one more round edits from Jon. Jon Peterson - Thanks for the feedback. Robert presented Gonzalo Camarillo tea (rapidly ripened puer eh) on behalf of the working group for Gonzalo's work as RAI AD. Room applauded. Gonzalo Camarillo - Ericsson will host IETF in Canada so I will still be involved in IETF. -------------------------------------------------------- 50m Signing/Verifying draft: draft-jennings-stir-rfc4474bis-01 presentation: http://tools.ietf.org/agenda/89/slides/slides-89-stir-1.pdf presenter: Jon Peterson Slide 2 - FIrst Principles (again) Jon - Any comments on separating the work into two buckets (signaling and credentials)? Russ Housley, as individual - this split between is in other protocols like SMIME and TLS. It's well worn path, we should follow it. Slide 4 - Credential Systems (5.4) Jon - Is this list of requirements roughly the right list? Sean Turner - how many enrollment processes? Jon - there can be more than one. It doesn't have to be any single one. I'm on the fence about whether should be in it or not. Robert - who has read the draft? Less than half of the room raised hands. Robert - I'm not seeing discussions on list yet. Brian Rosen - What if there is no URI in the Identity-Info header, and you learned it somehow elsewhere? Does the text assume a URI? We need a way other than URI to determine identity. Jon - 4474 has left it open. The only thing that ties Identity-Info to credentials is the selector. I don't want to suggest you do this. Something has to be in in the Identity-Info header. It could be DNS based for instance. Max Prichten - We should define an enrollment mechanism Russ - can you do that by reference? Max - that would be fantastic Russ - then we're ok. Jon - We could just pick one credential system, or we can recharter and consider multiple. Steve Kent - having just one is tight, but we're imposing restraints on the receiver if we have a lot of them - the receiver may not be able to support all or any. Should Focus on a smaller number. Jon - I don't think that credential systems should be negotiated by nodes. Not sure what is right. Brian Rosen - We really really want to have everyone do the same thing - all the phones, regulators, carriers. I don't mind multiple protocols to get the data. But we need one way to get this to happen. Keep in the mind we want a single global system to achieve the goals of the working group. Jon - letting lot of flowers bloom is a charter question, not a draft question. If you need an IANA registry, etc. My takeaway - we should constrain as much as possible. Not let a thousand flowers bloom. Slide 5 - Canonicalization Jon - stub in the document. This slide is the same as last time. At the last meeting, there was lots of discussion, no consensus. We can't make a 100% solution, but can specify how it's going to look, though. Will it look like ENUM? Brian - I believe there needs to be an algorithm that the receiver can run and produce the canonical string. If you run it on the producing side, and you don't get the same thing as the running side, then do something that fixes it - add something to the header for instance. More or less like ENUM. Need to deal with it in the text. If it's not a canonical E164, need to do something. Jon - do intermediaries do something is an interesting question. Brian - We need to decide and write it down. Cullen Jennings - needs to be a concrete algorithm. On country codes - the valid codes are a valid E164. It's misconfigured if the intermediary has to fix it, return an error or take a best guess, I don't care. It's equivalent work. Richard Barnes, as individual - a comparison approach may be more robust - what's signed is canonical as opposed to the dirty information that made it through intermediaries. Jon - We won't put the canonical form in the message, it will be derived from parts of the messages. Tweak it a bit at the start, so that it goes through. Are you saying we need a new header? Richard - it's the same work. If a header captures what the signer thought they were signing, you can debug more easily. The verifier would have the full info on what the signer was trying to convey. People should have the flexibility to accept dirtier information. Hadriel Kaplan - Are you saying that the thing you are signing is not in the message per se? Jon - let's say we created a new header. Identity-Canon - if it makes it to the end, great. The end has to still do the same work. Hadriel - the canonicalization algorithms are all different today but they create the same canonicalization. There's an existence proof. Jon - Those algorithms need to create something that's routable, not bit exact. This algorithm needs to have both sides come up with the bit exact info. Hadriel - I was thinking that the algorithm would specify that it has to start with a +, have a country code, etc. Not - start with the From header. If you are verifier, if you do it over the From ... it's in draft strikes. Jon - that's a nontrivial optimization Eric Rescola - Canonicalization has been a debacle. SMIME dealt with it by hardening the data being sent, and ignoring the data that's been mangled. Jon - we don't know what will be touched. Eric - put it in an opaque header, encrypt it. I don't understand the architecture - we'll do this compare procedure, if it fails, what will the user interface display? Jon - phone not ringing. Eric - Why can't I use the what gets signed in the display? Jon - Info in the From header field, whether that gets stuck in other header or each end comes up with the same info? Ekr - …. Jon - we're concerned about T-DOS and the other stir use cases. The presence of the From header, the canonicalization... Ekr - where's the bit set? You have a channel that you deliver - From header, and the rest can't deliver it?. If you can change the From... Hadriel - intermediaries will touch it. Jon - needs to be close to the end points. We need to talk offline. Hannes Tschofenig - We have some experience in OAuth. Not only do the developers get it wrong, we underestimated what the end systems can do. It wasn't available to the end systems. Test on the frameworks that you expect it to work on. For instance, Python messes around with stuff. Hadriel - another reason to have a copy of the canonical form, there may be multiple algorithms. Jon - I want to avoid it. Hadriel - May have just a local number in the From header, I received it from here, so I know that it's area code X. Cullen - The scenario that you don't know the country code and it may be multiple countries is very unlikely. Something like that should fail. This really isn't canonicalization. You can't reorder digits. You either are missing info or you are not. Jon - we do need to solve this. Cullen - before a draft goes to the IESG, I agree. Jon - … Cullen - I don't think that authentication can happen before authenticator figures out where it came from. Hadriel - the authenticator can know the country code, but can't add it because it would break things. This mechanism has to work with existing headers. You can't ask people to change how they create Froms and Tos. It's not a single hop decision. Jon - if you are going to act as the authentication service, you can change the From header. Hadriel - makes you a B2BUA then. Jon - if it goes internationally, then it will have to be modified anyway. Hadriel - read draft strikes. Robert called time on the presentation Brian - going back, we need to deal with service numbers, +1911 should work Slide 6 - Open Issues Hadriel - ECIPR was expiring this year, right? Soon, anyway. Smaller keys are better. I don't think we should do always-on integrity protection. Slide 7 - Way Forward Jon - the knobs and buttons are in place. This editorial pass was violent. Should we change any knobs? Robert - I want to get a sense from the room - is this the platform we should refine? Hadriel, anything else to consider as a starting place? Hadriel - we can change this draft up. It's this versus the strikes mechanism, which doesn't care that it's SIP. Jon - We do have a section on gatewaying into other protocols. It will be a separate specification. Hadriel - have to do it first to see we can do it. There are only so many bytes that can go into SS7 for instance. Jon - gateways are useful, I don't know if it should be in the core spec for SIP. Hadriel - strikes handles headers that the other protocols don't know. There's a translation table. Robert - I want to be working on one document by end of march or april? Can we start with 4474bis? Hadriel - We should be able to modify it. Russ - Do we adopt -01 or -02? Room wanted to get on with it. Russ - we'll do that next week. -------------------------------------------------------- 45m Credentials draft: draft-peterson-stir-certificates presentation: http://www.ietf.org/proceedings/89/slides/slides-89-stir-3.pdf Presenter: Sean Turner Slide 3 - Enrollment Sean - I hoping to hear from folks on this. Brian - I thought we had agreed that there was no golden root, but one CA per country because of the discovery issue. Cullen - A more realistic situation is multiple CAs for the same number. I don't think it makes are job harder. Steve Kent - picking as we go along worked so well. Learn from webPKI Jon - There will be a plurality internationally. Slide 5 - Telephone # Extension Sean - I'm not convinced this is right. This is a straw man. Jon - all the spid stuff, there are some use cases that a carrier would get lots of numbers … verifiers would use spid rather than TNs. We haven't talked about this yet. Slide 6 - Verifier Credential Acquisition Steve Kent - prefetch top 500 keys? Based on what? Callee? Country? What context? Jon - 500 is arbitrary. Certs by major carriers. ATT uses one for lots of numbers. Have a pub/sub system to subscribe to changes. Slide 7 - Expiry, Revocation and Rollover Jon - Pull method - if you have Identity-Info that you will dereference, it can be compounded with a freshness check. It's an optimization. Steve - people need to be clear about the security considerations for pull method. Sean - These are well-known warts of PKI Brian - we need something like this. If a carrier has a small number of certs, and their numbers changes, and that happens a lot. Need to know if the cert is valid for than number at this time. Hadriel - I think it won't scale. Porting numbers is not an issue. The real concern is if a carrier's keys is hacked. They need to revoke quickly. Porting - if you moved a number from ATT, ATT still needs to sign. Apple covers random numbers. Apple is going to want to wildcard - trust us we're apple. Steve - Breaking a number range into a bunch of certificates would reduce churn. Cullen - The worse case is a cert for one number, the billing issues are bigger for this than managing the cert. Slide 8 - Open Issue: Private Key Provisioning Jon - I hope the security folks can help here. Brian - need to write down what the right thing to do - phones ought to do, carriers ought - provide the advice. Can't say MUST, but can say SHOULD. Need something for phone manufacturers. Slide 9 - Open Issue: Public or Confidential Credentials? Jon - this is more fundamental that certs. What do we want to do? Do all certs have the same private key material? How important is endpoint participation? Don't want to build a system that only the large carriers can participant in. Need to figure this out. Privacy ... Alex Bobotek - it's not difficult to determine who is the owning carrier. A common model - the carrier is the authenticator. However, the originating carrier and owning carrier are not the same. The authenticating carrier is the owning carrier, not the originating carrier. Slide 10 - Open Issue: Partial Delegation Brian - Don't make it part of the original work, but we should cover it. Slide 11 - Open Issues: Ranges by Reference Jon - We don't have a strong intuition about which is the best yet. -------------------------------------------------------- 20m Update: M3AAWG Voice and Telephony Anti-Abuse Workshop presentation: http://www.ietf.org/proceedings/89/slides/slides-89-stir-2.pptx Presenter: Alex Bobotek Slide 4 - Similar to Email, Malware & Internet Abuse Alex - dealing with it is the same - Shut down the accounts, bring in the regulators. Needs to be a holistic approach in media and enforcement points. There's RCS, VolTE. MESSAGE will replace SMS. More SIP than just VoIP calls. Slide 7 - VTASIG Meetings/Workshops Alex - Can look at spectrum to determine where a call came from. India uses different spectrum than US. Slide 10 - VTASIG Future Jon - I was there in SF. It's a great forum with a different constituency. I commend you for undertaking it. I'll continue to participate. Hadriel - thanks for coming here. Do you announce on the voice-ops mailing list? Alex - no Hadriel - announce through SIP Forum too? How do you become a member? There are lots of mom and pop service providers out there. They cause a lot of the problems. Alex - Oracle is a member. Mom-pop service providers are most needed as members. It's a non-profit organization, memberships are not several thousand dollars. Dan York - thank you for bringing this here. We can promote this in other circles. Have you involved the OTT organizations - Facebook, Whatsapp? Alex - they are involved. We've recognized that the it's an expanding ecosystem. Robert - This meeting was short due to the mmusic collision. Please sign blue sheets. END - Notetaker: Peter Yee ------------------------------------------------------ 2014-03-03 (0900-1130) STIR The -threats document is doing one more round before going to the IESG. Jon Peterson (NeuStar) has the pen on that. rfc4474bis (Jon Peterson) Work will be separated between signaling (what fields are signed, etc.) and credentials (how signers enroll, etc.) 4471bis will cover the signaling parts, with credentials separated into another document. The signature will cover the To/From/Method/Date headers. Identifiers could be telephone numbers or SIP URIs. Other identifiers would require specifying an acceptable credential, but this isn’t out of the realm of the possible. There will be an optional Identity-Reliance header which is optional both for the signer to add and the verifier to check. The Identity-Info header is now much broader, allowing the identification of which of several authorized parties performed signing. This covers more than certificates as in RFC 4474. There is a stub for where canonicalization text will go. Otherwise, much of what is RFC 4474 will be kept, including response codes. Any credential system to be used with the STIR signing mechanism must specify which URI schemes are permitted with Identity-Info, how the verifier learns the scope of credentials, how to extract keying material from the resource specified in Identity-Info, and any algorithms beyond the RFC4474bis-specified algorithms. Max Pritikin (Cisco) doesn’t want to see a proliferation of credential systems, which leads to multiple enrollment and verification systems. Steve Kent (BBN) suggests that the number of credential schemes should be limited to ensure that there is at least one in common before signer and verifier. Brian Rosen concurs with Kent and Pritikin. Certificates would follow the RFC 4474 model – X.509 certs which can contain telephone numbers, with a new CA (or small set of CAs) issuing certificates for STIR purposes. The representation of telephone numbers will require canonicalization to E.164 format. Perhaps reuse of ENUM’s procedures will suffice? Richard Barnes (BBN) doesn’t mind carriage of a non-canonical identifier form as long as the call recipient can use the non-canonical forms to derive the canonical form. The caller’s identity is conveyed in the From header, at a minimum. That value may get tweaked across the call path, but both signer and verifier must be able to arrive at the canonical form. EKR (RTFM) thinks canonicalization is a rat hole. Why not just show the identity determined by the verification step as the caller ID? Rescorla wants to see a diagram because he doesn’t feel it’s at all clear where canonicalization occurs and how verifications are signaled (especially if the verifier is not the call termination point). Cullen Jennings (Cisco) believes that telephone number canonicalization is well understood and there really isn’t a difficult problem here. Hadriel Kaplan (Oracle) feels that adding in a country code to the From header is a difficult thing and may fall afoul of intermediate systems, while Peterson disagrees with him. Kaplan suggests that the STRIKES draft be consulted for a discussion of the issues. Open issues: editing and clean up of the draft, canonicalization, credential has in Identity-Info to speed up processing, always-on integrity for keying material in SDP, and signing algorithm (should elliptic curve be specified for small key size)? Robert Sparks (co-chair) would like to see a version of this document ready by the beginning of April that the WG can start to provide edits and input to. STIR Certificates (Sean Turner (IECA)) Use of certificates is not to exclude other credential systems. The draft defines a certificate extension that covers telephone number ranges. It also defines certificate enrollment and authentication for the STIR use case. There are three methods for enrolling for certs: direct assignment (from telephone number holder), delegation from above (as a partition of a number range), and proof of possession (of a telephone number). There’s a difference of opinion on whether there is a “golden root” (one CA per country) or multiple CAs are allowed. It seems unlikely that we can force a single CA, although Steve Kent cautions that the WebPKI experience has shown how badly multiple CAs can work. Certificates should be able to cover ranges of telephone numbers, not just single telephone numbers. This mirrors telephone number delegations outside of security. There are various means of obtaining verifier credentials, including push (certificate arrives in the SIP request), pull (certificate is retrieved as needed), prefetch (a bunch of likely calling certificates?), or other schemes. Expiration, revocation, and rollover all have to be dealt with. Telephone numbers get ported which require a new certificate. OCSP might be used for real-time revocation checking, although Steve Kent points out that pre-signed OCSP responses might foil good revocation checking. How to get the private key to the signer is a concern. Another is whether certificates are public or credential. Would public certificates lead to a privacy leak or have repercussions we haven’t considered? Would it be possible to limit access to certificates? Alex Bobotek (AT&T) noted that it isn’t that hard to determine which carrier “owns” a telephone number. Certificates aren’t really making this state of affairs easier or harder. Telephone number ranges could be quite large. It might be useful to include ranges by reference rather than by value. This would allow smaller certificates. A URL, for example, could be used to specify where the range values can be retrieved. Presumably the range values would be included in the signature. M3AAWG Voice and Telephony Anti-Abuse Workshop (Alex Bobotek (as M3AAWG co-chair, not AT&T)) M3AAWG is the Messaging, Malware, and Mobile Anti-Abuse Working Group. It is an industry non-profit forum for service providers. It has expanded into the voice area as more and more voice calls are originated off of the PSTN and such calls start to see the abuse problems common on SMS, e-mail, etc. It produces best practices, education, requirements for standards (but not standards), and collaboration. Participation from non-industry parties is permitted on a limited basis.