Stir Status PagesSecure Telephone Identity Revisited (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2013-Aug-30 —Chairs:
IETF-99 stir minutes
Session 2017-07-19 1330-1500: Karlin I/II - Audio stream - stir chatroom
Secure Telephone Identity Revisited (stir) - IETF 99 - Prague 19 July, 2017 : 1330-1500 - Karlin I/II Summary: * draft-wendt-stir-passport-shaken needs more reviewers * draft-ietf-stir-rph will be revised reflecting comments to date. We expect to WGLC that revision. * draft-ietf-stir-divert is close to ready. The remaining open issue is whether to include the reason code. Mary will complete an investigation into use-cases to see if there's a compeling reason to sign over the reason code. Chris and Mary may provide call-flow examples. * We identified several areas to work on in draft-ietf-stir-rcd. * We reconfirmed that the working group has abandoned the approach in draft-ietf-stir-certificates-ocsp, and discussed whether the draft should be published anyhow. The sense of the room was that the draft should not be published as an RFC, but discussion should conclude on list. Work on certificate freshness has moved to ACME, in particular with ACME STAR. draft-peterson-stir-certificates will tie STIR together with that work. We expect to issue a call for adoption on the next revision of that draft. * We discussed several points to change and add to draft-ietf-stir-oob. Discussion will continue on list. Raw notes from Jean Mahoney are below. Note that Meetecho now provides a text transcription with the recording. If you see anything below that puzzles you, consider checking the recording at ============================================================================= "Looking through the draft I had two things just reminding me of old crap frumpy kicks" Secure Telephone Identity Revisited (stir) - IETF 99 - Prague 1330-1500 - Karlin I/II ------------------------------------------------------------------------ 1330 5m Administrivia ( Chairs ) Note taker: Jean Mahoney Jabber scribe: Jonathan Lennox Robert Sparks: any changes to agenda? (no one had changes) 1335 5m SHAKEN passports (Chris) https://datatracker.ietf.org/doc/draft-wendt-stir-passport-shaken/ https://www.ietf.org/proceedings/99/slides/slides-99-stir-passport-shaken-00.pdf slide 1: Title slide 2: SHAKEN PASSporT extension - Attestation and Originating Identifier slide 3: Example SHAKEN PASSporT extension RjS: Who has read this draft? Not as many hands as I'd like. Read it. If you have any issues with making it a WG draft, send to the list. ------------------------------------------------------------------------ 1340 15m Resource-Priority Authorization ( Martin ) https://datatracker.ietf.org/doc/draft-ietf-stir-rph/ https://www.ietf.org/proceedings/99/slides/slides-99-stir-passport-rph-00.pdf slide 1: Title slide 2: Outline slide 3: Background and Overview slide 4: List of Updates in Draft-ietf-stir-rph-00 slide 5: Open Items and Proposed Resolution slide 6: Next Steps Robert from floor: Thanks for addressing my comment about multiple authorities. I'm still confused. You have a call that comes in, there's a signature passport object that makes an attestation that the person who placed the call has authority to use the number. Is that the same passport that is extended with the RPH. So it is a second passport object? Martin: Yes RjS: make it obvious in text. Martin: we debated having a single signing. You are authenticating the user - The end user enters credentials to be authorized. and would take precedence over the use of the phone number - can be used by the user on any phone number. When we worked through use cases, needed to keep them separate signing. Russ: It's a second passport with second signature. Martin: Yes, thank you RjS: Who has read? (hands) Good coverage. Could go to last call? (nods in the room) Martin, reflect this conversation in the updates and then we'll LC before Singapore. ------------------------------------------------------------------------ 1355 15m Diverted Calls ( Jon ) https://datatracker.ietf.org/doc/draft-ietf-stir-passport-divert/ https://www.ietf.org/proceedings/99/slides/slides-99-stir-divert-and-rcd-00.pdf slide 1: Title slide 2: draft-ietf-stir-passport-divert-00 slide 3: Inverting the signer slide 4: Original vs Divert Passport slide 5: Issues Mary Barnes: I think we do want a reason. History-Info captures the reason code and it captures how the diversion happened. That info is useful. Jon: Do we need to sign it? Mary: I'm still debating. It adds value in the application. I've written a draft. Jon: Is there a threat model here where somebody will create bogus History-Info simultaneously with being able to sign for these divert things? Mary: The situation we do have - people are removing history-info history. Still have valuable info there if that happens. RjS: Jon said - by adding this, we cause people to remove identity. Mary: I'll work some more cases. Brian Rosen: I have a use case. In emergency services, there are legal things that happen with records - how did a call get handled and a provable way of documenting what happened. Reason headers are diagnostic - we don't need cryptographic assertions on that. Russ, from floor: When designing the original passport, we wanted to winnow down to the smallest amount - if there wasn't an attack thwarted by signing it - don't sign it. Apply the same metric here. Martin Dolly: we have use case - Financial institutions' IVRs that forward calls to desks. Russ: To clarify, Martin, yes, you want divert. Do you want the Reason code? Dolly: No. Chris Wendt: You have identity headers that are A to B, B to C, C to D, and if you're missing B to C, you're missing something. Comcast, CableLabs went through these use cases - we've landed on what Jon has proposed. RjS: seems to me that this is baked, except for including Reason. Mary, can you finish your analysis soon? Mary: Mid sept - I'll sign up for that. I'm working on call flows. Chris: I can volunteer to create call flows as well. Jonathan Lennox: the extensibility model is such that not doing reason now doesn't stop me from doing reason later Jon: put a sub element in div that has extensibility or it could just be a separate thing that we put in the passport. ACTION: Mary to complete draft of use cases. ------------------------------------------------------------------------ 1410 15m Rich Call Data ( Jon ) https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/ https://www.ietf.org/proceedings/99/slides/slides-99-stir-divert-and-rcd-00.pdf slide 6: draft-ietf-stir-passport-rcd (formerly cnam) slide 7: First and Third slide 8: "rcd" without "ppt" slide 9: "rcd" with "ppt" Chris: A first party entity could do the same thing, right? To give it more credibility. I'm not clear on the passport. Jon: back on the previous slide, the entity that signed this regular passport is the responsible entity. They have an OCN in which that number lives, and this is a valid signature for all this information including the nam, so entity signs for it on the basis of their authority or that you trust that the name is for that number. Next slide. In the third party case, this is a cert from someone who does not have authority over that. Chris: That would be another identity header assuming that it would be okay. Jon: Yes, a different ID. Suhas: With ppt, is there any case that it couldn't go again? Another third party - is it possible? Jon: Because there could be multiple 3rd party headers? Sure. Suhas: this does not prove it to add more. Jon: Right. A verification service is going to consume the set of identity headers that are associated with the call and extract the set of passports from it. It'll look at the signatures on those, and it could be that it trusts this entity who signed this third-party passport. Or maybe it doesn't. It models the way these kind of third-party services work today. It models what 3rd party models work today. They're a verification service, we trust it for the business relationship. Martin Dolly: You should look at when you have multiple identity headers associated with different authorities - the impact on post-dial delay. slide 10: Issues: LoA Jon: You want to know why people think what they think about who these callers are. We see this in SHAKEN's attestation fields. There are cases where you're a carrier signing for your direct customer. There are other cases where you are a reseller with a block of numbers, but you don't directly assign those numbers to specific customers, and maybe you get stuff from somebody else. We may need something similar to SHAKEN's various attest levels. Once shaken is specified, we can use that. We may crowd-sourced information that could tell you the name associated with the telephone number, and when we provide this, we want to provide some sense to relying parties of how good we think this data is, and we want our CDN to be flexible enough to be able to express that. slide 11: Other Issues Jon: Once we start carrying location information in these objects, I start to get nervous about the privacy implications as this passes through the telephone network. We need a confidentiality story if the information in the passport becomes more sensitive. We need to specify the interface for third-party passport acquisition. Probably out-of-band, but we can talk about it. A kind of HTTP that you use to talk to the CPS. Another band to ask for passports. It'd be nice if we could guarantee that people would let information like RCD propagate down to the users. Next steps - there's more to be done. This will have a few more revs. Paul Hoffman: you are assuming that you are displaying text to user. Think about that. Jon: I don't have a restriction on text. I think logo is in the somewhere. Paul: For the ones that might return a URL. Is a URL that you want them to resolve right then or later? Jon: One that can resolve right then, like if you want to get a vCard and I would provide a link to it - Paul: As compared to my website which you don't necessarily want to resolve right away - Jon: yes Paul: that will need to get out there, and if you had two categories of things that might return a URL - ones that are informative and ones that are resolved now - that would be good Hala Mowafy: What do we gain from getting the attestation levels for additional information? We could just follow ... for your number, which will get us everything. You said if it's not available for the name, that you'll rely on the attestation for the number. Because of US regs, we're must follow every detail related to that number - like privacy of name for the number. There's not a separate privacy label for name. This extends to metadata that you might present. Why get a separate ... because I'm worried about the processing - Jon: A party relying on a verification service for this will be presented with the set of identity headers. If the doc says this then it's premature. I'm not dictating policy for what you accept and why. It will depend on things like trust relationships. A profile like shaken - our profile developed at Addis - can take this mechanism and say for the North American use case, you must do these things and follow these policies if you're going to play in this particular carrier ecosystem. IETF wouldn't say that. We would leave it open. Hala: There are a lot of parameters to analyze before you decide whether to display a warning or not. If the list the branches to search just extends more - Are we complicating the picture? Why isn't following just the attestation of the number sufficient? Brian: In 3/4 of the cases of caller ID in the US are provided by a third party - that's the answer. The third party has to be able to supply the information. The caller ID comes from a contractual agreement between the termination carrier and the third party, but the third party is the one that's supplying the data. We're trying to do a cryptographic assertion that the name is correct for this number. That assertion is coming from a third party. This claim does not assert that the caller was a particular number, it's saying that the name associated with a number has to be the one that's in the origination. Hala: So why are we talking about at a separate attestation for that name when I've already verified the associated number that was just traveling in the same message? Chris: Comcast contracts out to Company A for calling name services. Does Comcast want to be legally liable for what name comes back? Or do we want to have a attestation that states you know where to subscribe to a service? We're not populating AT&T customers names. Jon: we are not specifying policy on what the carriers trust. Hala: How does the carrier attest for social media. Jon: I don't know. Maybe customers will tell carriers. These data structures are just available, we don't know if they'll be used. Chris: I'm ok with the flexibility can use it or not. Paul: I was assuming it was all 3rd party. Jon: I won't say that, a lot of 3rd party. But location but maybe originating carrier is the source. Paul: there's going to be reputation scores for the parties. The 3rd parties have better reputations than 1st party. Jon: I'm so not going there. Chris: there's use case for 1st party attestation. You are relying on the number to be correct. Jon: we are stir RjS from floor: go back to Examples slide: clarify the semantic - you anticipate this being used when there is a single authority. You'll have a single signature, one identity header, and that entity means both that we've verified that the person placing the call has the authority, and that the binding from that number to that name is valid. 2nd slide - this is a second signature. The first signature talks about the person making the call is determined to be authority to use the call. The second signature speaks only to the association of that number with that name. Add text considering the attack were the first identity header is removed. This is the only one you get. I can see someone make the mistake that this looks like a base passport, so that means that number has been determined to be authoritatively connected to that caller. Add text to make sure that no implementor will make that mistake. Jon: maybe we ought to change some of this. Brian: The third party is not asserting that the origination is that number. It is not asserting that that destination is that number. Maybe it should claim something else. Jon: I thought about not doing this with passport. I'm not clear yet on that trade off. It may matter what the test is for these connected identity cases coming down the pike. Chris and I have talked about it. Having those there might be helpful, but I am definitely terrified of what Robert just said. We need to fix that. Chris: You know what you know, and you don't know what you don't know. I think it's good to tie it, and I think Diversion may play here. There may be good use cases to come out of diversion. Jonathan Lennox: It seems like some way of claiming that I say this name corresponds to this origin - something syntactically different that says you know the input to my process was this or - the way that passport is defined, those things are mandatory, so we could do something like this. We could make a new sub-element that means this is something different, and your a phone number the origination is a passport could handing a telephone yeah yeah and we did that and maybe there's a lot of options like that - Jonathan Lennox: Claim the input into my process was this. The origination is not a telephone number but a passport containing a telephone number. Jon: I welcome feedback. It's not baked yet. Brian: I think it's going in the right direction. We've got an example - is this what we want to see? I think this first-party third-party thing is what we want. The questions raised about doing reputations on third parties needs to get in the text. And this discussion is important to get in the text. Jon: Thank you. Any other comments? Robert: agenda bash - ekr is called away. Let's talk about freshness first. 1445 20m Certificate Freshness ( Sean Turner ) continuation of discussion slide 1: Title slide 2: Two real paths Sean: If the OCSP draft dies, I'm okay with that. We need to come up with a good mechanism. RjS: I think the working group has acknowledged that that draft is dead. slide 3: Short-lived Credentials slide 4: Short-lived slide 5: ACME makes short-lived easy slide 6: ACME interactions Jon Peterson: Martin commented about this on list. Why didn't we stick spc into the subject name or some other field? If the TN auth list contains this bundle of codes, which in North Am would be OCNs and TNs, are the two identifiers interchangeable? If you can ask the NPAC what are the OCNs associated with this TN and vice versa. Because you can delegate, or if I can get a cert, and we identify a token format that can say - as the authority signing for this OCN - I say it's kosher for you to delegate this TN to this user, which can do through ACME STAR - all kinds of mechanisms that we're building over there that will work. I think this is going to work. Chris: How do you tie the certificate specifically to that? With a unique ID or something? we need to clarify. Sean: Fair enough slide 7: ACME STAR Jon: We need STAR to be more generic to be applicable to this case. STAR contains this language about DNO domain name owners specific to the lurk problem space. I think you could make it more generic. You can expect me to talk about that in ACME on Friday. Sean: The problem was narrowing down these cases. Lurk didn't go forward because we couldn't narrow it down. If you say what you are going to use it for, you could narrow it down and solve the problem. Rich Salz, ACME co-chair: We split the STAR stuff into short-term automatic renewals. Delegation is separate. Everybody agrees Renewables is good, no comment on the second. It's more tractable. Sean: I think we could adopt it if we narrowed it down. It wouldn't be a stretch to say that it fits this particular use case. We can adopt it and work on it, as opposed to having a BoF to figure out what we're gonna do. slide 8: So what to do? Brian Rosen: I'm fine with the proposal. We need some text that talks about - Although the cert itself is short-lived, that's the time at which you can do assigning. Need to talk about how you retrospectively determine whether or not this really was okay. Sean: This is how do you do PKI based stuff. Initially when they signed stuff, they duffed it so when the signature was valid back then, but your current time clock was past that date, it would show it as invalid. They had to show it was good back then. If you did that same phone call now, it wouldn't be valid. There's ways that we can explain that. Brian: I don't think we have a problem, we just need words in the document that explains it. Sean: That's security consideration #1. BTW a signed phone call is good for a validity period of this. Based on that, you can keep using the cert if you like, but the call won't be good anymore, and the call is still also good in the past. Paul: that's an important point. Security consideration #2 - what kind of CAs do you trust? I work at ICANN and we have a whole bunch of different CPS's now for things that we do, which aren't aligned based on - is there an OCSP responder for this CA? Do we publish this yet? Saying there is no expectation for OCSP, SCVP, or even CRLs from these CAs would be a good thing. Sean: to get into the weeds, I would like put that in the CP in the CPS but then say what we do or not, and you would actually put - Paul: In the security considerations, say that CPs for the CAs who might do the short-lived certs are not expected to do, and list the things that an outside person who is used to CPs from the web trust world would expect because we're getting hit badly with that. Sean: we will try to clarify, so the people that are providing me certs know what they're looking for, what they're not, and make it clear that this ain't web PKI. Chris: There isn't any explicit tie between certs and calls, right? If I have a two-week cert, I can originate multiple calls with that. Sean: Yes, but you could do it per phone call if you want. Don't know why you would. Chris: you could get more certs and then so - Sean: the times would overlap and craziness ensues. Jon: If you own a large block of numbers but didn't want to reveal the block, you could get a short-term cert for a single number to place a single call. Every time you made a call, you got a different cert. Have to be pretty paranoid to be concerned about your data being collected. Sean: one concern was - You've got a block of numbers, and you don't want to expose it in your cert by saying I am authorized for all of these. You just do one at a time. You'd have to be super paranoid, and also have a pretty good infrastructure to support the fact that you can issue all those certs. Jonathan Lennox: Will there be ops guidance on how soon you need to get your cert? Sean: Yes, but we provide the mechanisms, and other groups will specify what it is, and how fast they want it and what it means. Jonathan: what happens if you're 50 a minute before their cert expires and the CA is down. Sean: absolutely, great point. Thanks to Russ again for writing lots of security considerations about PKIX related stuff. It's already documented. We can point to it or pull it in. Jon: I think STAR says you need to do it halfway through your expiry interval. Sean: It's a good way to do it. Since the OCSP draft is dead, we should ask for wg adoption for the short-lived cert one. Jon, do you want to rev it a little bit more? Jon: I'm happy to adopt it. We could publish the OCSP one because it's basically done, just for the sake of having the solution documented. Sean: We cut it out of the stir cert draft because it has privacy considerations. If we bolstered the security considerations, which I think are fine, and just finished it, would be great. Maybe it's informational. If you want to do historic, I don't care. Jon: Or it could be an ID and on the way back - Sean: whatever, I don't care. RjS: is there value in pushing it through the IESG? Paul: Don't send mixed messages to somebody three years in the future who doesn't know what this is, but needs to apply some security stuff to it. Having an RFC that says OCSP will make them think OCSP is important. Sean: We could put in the draft - we thought about this, we publish it for information, go look at this other draft because that's the way to go. I'm happy with Paul's suggestion because that's one less thing to track. To the chairs: Can we call for adoption of the short-lived cert stuff? RjS: Does the draft reflect where we're going? does it talk about the STAR stuff? Who has read the short-lived draft? Let's give people some time to read it. call for adoption on list. Massimiliano Pala: Will the short-lived draft prevent people from using longer lived certs and using OCSP? RjS: The message is - Here's how we should do it. We can say in here that we talked about the other thing, but don't provide details of the other thing that we don't want people to do. Brian Rosen: I don't want two mechanisms and then deal with the interoperability problems that two mechanisms provide. I'd rather let it die. Chris: Our concern with OCSP long-term is the scale of it. We prefer the short term certs. Sean: yeah, we could we could do this, but is it gonna get done? RjS: I'm hearing that there needs to be more words on the list. We need to leave a good fossil record about this conversation. Subir Das: The length of the short lived cert - day, week, or hours - that will be defined somewhere else, right? Sean: We provide a mechanism to indicate it and say that we're not talking years we're talking less than that. Some other group -regulators or industry - can say do it for a week or two days. Subir: Not in IETF. Sean: Right, we're not the operators. We're just providing the means. If you make it too long, here's a problem, if you make it too short, here's the other problem. Just pick something smart. Chris: need operational experience before locking it down. Sean: agree. 1425 20m Out-of-Band ( Jon ) 1442 https://datatracker.ietf.org/doc/draft-ietf-stir-oob/ https://www.ietf.org/proceedings/99/slides/slides-99-stir-out-of-band-00.pdf slide 1: Title slide 2: Limits of RFC4474bis slide 3: Basic STIR Out of Band Martin: How does the originating UE know the capabilities of the terminating UE before they initiate a call to know to store passport? Jon: They don't, leap of faith. The practice would be - if you're a SIP entity sending a SIP invite, just store a passport just in case. If the call drops to the PSTN, and it could determine whether someone supported this, might be able to get it. We want to make this work in as many environments and architectures as we can. slide 4: Obvious Questions slide 5: Who Gets to Store PASSporTs? slide 6: Do you need to authorize? slide 7: The Three Retrieval Semantics Martin: Based on your figure, neither the originating UE nor the originating network will know at the time where they would do signing, whether you're going to hit a PSTN gateway and go through your scenario. You could have a situation whereby you know you're going to get the passport coming from the CPS and receiving it in SIP signaling, assuming there was no PSTN in the middle. Jon: The verification service has to go out of its way to ask the CPS, so if it gets the call, it's got a passport it can use in the SIP signaling. It's not going to ask the CPS. Martin: That's what you're assuming then. Jon: There could be multiple entities involved in the creation of identity headers for this. I don't want to rule out that's one entity you might have used the CPS and one put it through SIP signaling. If you receive the passport through SIP signaling, it would be redundant to look in the CPS, if you can use what's there and can decide whether to alert the user. Chris: Are you thinking of the security of these requests so that I couldn't just go incrementally through all the numbers and request B - Jon: The authentication component of this is why B looks - because giving me passports for the call number is great when I'm the entity that owns that number and I have a cert to prove it. We want some mechanism like that with the following caveat - slide 8: Encrypting PASSporTs slide 9: The Least Worst Way? Chris: what if it represents a block of numbers? Jon: works same way. Chris: you would just get all the calls in progress for that block of numbers? Jon: potentially. When you say "calls in progress", you will get all calls that are in the process of being set up for the lifetime that these blobs exist in the CPS at this time so if you are dealing with 10,000 calls a second for your number block, you will be asking every second for all the passport blobs that are associated with that. Jonathan: it seems like the without some significant chaffing, the key query mechanism is an interesting perpass target, still. Jon: If these ask for keys only at the time they're placing calls - yes, perpass target. If you create dummy traffic or you constantly ask for keys for different things, then it's harder to guess who's calling it. Jonathan: Often the reason I'm using PSTN rather than the internet when I have both is because my internet is crappy at the moment. If I have to take a calling out to query for a key, download it, do the crypto, upload it, that may take longer than it takes the PSTN call to go through. When the called party queries, and there's nothing there, can he can try again or ask if something new shows up in the next 30 seconds - ? Jon: The verification service acts the time frame users are alerted. You don't wait to alert until this resolves. typically. You may have more grace time than you think. RjS: we're at the end of our time - maybe can go 5 over. Jim: Where would those public keys be stored and how would people find them? Are we talking about throwing them into DNS and assuming something like ENUM? Jon: There's going to be a service - it may be adjacent to the CPS in some way. We might be able to do some things with CPS integration. But this becomes a perpass target. slide 10: Remaining Challenges Jon: We need to figure how to work this route divert. The service discovery component of this is a TODO. slide 11: What about this case? Jon: This doesn't work with cases where on side B you need to authenticate yourself to the CPS. If you got an encrypted blob from CPS, you could stick that into the SIP traffic if we had something like a SIP identity encrypted header, which we don't. We could do that with a PBT - there's many ways we could syntactically represent it, but because of those RCD-ish cases, I think we need a standard way in SIP to carry an encrypted passport. slide 12: Next Steps Jon: We have a lot more to do. What I presented today is not in the draft. We've got to figure out a ton of stuff about it. Please send comments/ideas/objections.