STIR WG IETF 105, Montreal, CA Monday, 22-Jul-2019 10:00-12:00 Duluth Summary: Discussion of draft-ietf-stir-cert-delegation expanded to take the entire hour, and will continue on list. The chairs will schedule an virtual interim in September to follow-up and to make progress on draft-ietf-stir-passport-rcd. ------------------------------------------------------------------------ Detailed Minutes: Administrivia Chairs: Robert Sparks, Russ Housley https://datatracker.ietf.org/meeting/105/materials/slides-105-stir-chair-slides-00 Minute Taker - Jean Mahoney Jabber Scribe - Eric Burger slide 1: Title slide 2: Note Well slide 3: STIR WG Agenda Robert - anyone have an agenda bash? Brian Rosen - I would like to talk about emergency calling and what would be necessary to make a call back from the 911 system. If the 911 system wants to, and they often don't, show a 3 digit number. Robert - if there's time. Martin Dolly - IP-NNI is working with ECIF to define requirements for when 911 is dialed getting to PSAP and getting a call back. ------------------------------------------------------------------------ STIR Certificate Delegation draft-ietf-stir-cert-delegation Jon Peterson https://datatracker.ietf.org/meeting/105/materials/slides-105-stir-stir-certificate-delegation-00 slide 1: Title slide 2: draft-ietf-stir-cert-delegation-00 slide 3: Why are we talking about this? slide 4: SPCs and TNs Mary Barnes - There are non-carriers that have OCNs. Jon - Yes. The draft doesn't say, don't do that. There are cases where you want to do that. There are other cases, say, an enterprise that has had numbers for twenty years, nothing gets ported in or out, they're contiguous. It might make sense for these entities to use TN blocks themselves in the certs. One size doesn't fit all. Sometimes OCN is overkill. The hard edge is the concept of "encompassing", we stole this idea from RKPI. This is an open issue in the draft - the terminating side needs to determine if the call should have been signed by the signer. Need to understand where in the architecture to make the encompassing check. Could do it when certs are issued or realtime during call processing at the VS. Could impact call setup time. Could do it in both places. Mary - We have a dependency on existing identifiers assigned to service providers. Complicated because of number portability. If you check on the verification side - have to check in more than one place. You could do it on the authentication side - bind the CA token with the OCN and the TN. Jon - This architecture would allow you to bind an OCN to OCN as a delegation. Mary - We have the notion of overall OCNs as well. Jon - Where do we want the authority and responsibility to reside in the architecture? My preference is that it happens offline rather than during call processing. Mary - Whether or not we can make that decision here, we need to provide the tools. Jon - We do the plumbing here. We can offer guidance on tradeoffs. Mary - I don't think we'll say you can only do it this way. Jon - I wouldn't leave the certification out. The AS is also during call processing. Mary - Can do it with the SPC token. Jon - You could. Chris Wendt - It should be possible to do lookup on LERG and NPAC and there's a mapping there. Enable on both sides and let folks chose the front end or back end. Jon - Definitely. Chris - The key is that the end-to-end can be validated on both sides and you don't have to trust one side over the other. Jon - Verification services are going to access all kinds of analytics before alerting a user, any number of checks can be performed. Russ (WG Chair hat off) - The CA should check what it can before it issues the certificate; this is important for the reputation of the CA. There's an interval where certificate is valid, but things around it could change. Allowing validation later is not a bad thing. We need to accommodate those checks by people who can't do an NPAC lookup. Jon - That's the virtue of having the TNs be inscribed themselves for these enterprises in cases where it does work. Having TNs in there helps the verification service that normally doesn't interface with the NPAC and the LERG. Richard Barnes - +1 to what Russ said - the CA should verify things - those are ground rules for PKI. Need to make sure we're not engineering ourselves into a circle. If these things can only be verified by doing a live check, the PKI is not adding value. Given the sunk costs for PKI concepts, don't throw that way. Sean Turner - I don't know how you would write a CP that says in the validation section, "put whatever you want in there." No relying party will buy into that. You have to do pre-validation somewhere, otherwise what's the certificate good for? Jon - It puts a requirement on the CA to have access to those resources. Need to note in the architecture. Mary - As long as CAs are willing to buy into it. Jon - The CA and PA functions are modularized in SHAKEN. We don't design SHAKEN here. We aren't going to decide whether it is the CA's job or the PA's job. Mary - The databases are not real time. Daily downloads are a newer feature. Chris - The CA should be able to rely on the authority token. Jon - Agreed. This is part of why we're not saying what we want to do in ACME because we're trying to figure this out. Richard - The "A" in "CA" is authority. They exist to make statements upon which other parties rely. slide 5: To CA or not CA? Eric Burger for Wilhelm Wimmreuter - Do they want to delegate Endpoint or CA-Issuing certificates? Jon - We are talking about potentially delegating CA-issuing certificates. Multiple chains of delegation - SPs that get numbers from a carrier that then provide those numbers to multiple customers. I can imagine multiple levels of delegated certificates. For typical operations, you as carrier would give your enterprise an EE certificate. Sean - If you decide to do TLS subcerts, you will get free security analysis to make sure you aren't blowing up TLS. This idea might be better because there will be a formal proof to show the security works. Jon - My preference is classic X.509 delegation with the CA bit set. If there is a market constraint against that, I would be willing to build a variant of subcerts just to get something out there, but that is not my preference. Max Pala - What about proxy certificates that are X.509 certs with everything just restricted delegation. They are meant to delegate to someone else without being CA. Jon - There is not a lot of them support the narrowing of the scope of the name. Mike - It's up to who is validating the certificates. Jon - We want the CA to tell you what you need to do to validate without having to do an external check. If we hope to build that into the certificate, we need something that has a particular set of qualities. Think about RPKI encompassing, if you have a /16 and you want a subcert for a /24, does that work with proxy certificates? Russ - Yes, but not using the name constraints extension. Jon - We don't use classic X.509 name constraints. We can look into it. Good suggestion. Cullen Jennings - Either of these paths solve the problem. I lean slightly toward subcerts. When I tell an operator or an SP that they will need to manage private keys for a certificate, they say, "Oh, no!" But if I tell them that they need to manage a token that enables you to do everything, they don't have problems with it. One's easy, one's hard, but they're the same thing. Richard - I lean slightly the opposite. The X.509 delegation is cleaner. There's more machinery, it just works. The subcerts can be made to work, but it's greenfield, would have to add stuff to make it work with multiple levels of delegation. Jon - We would have to do another draft. Richard - There's running code though. You won't get the interoperability that PKI has. Between STIR-specific PKI and subcerts, might be a tie. Clint Wilson - I lean towards the subcerts. We've working on implementing, it's more tenable from CA implementation perspective. The X.509 delegation is a big no-no in web PKI, harder to make ... that supports that ability. Jon - I am sympathetic to that. Nick Sullivan - TLS subcerts is a key delegation, not a credential delegation. It takes what's valid in the certificate and narrows the scope. I don't see a problem with making a different variant. This draft is for key lifetime narrowing. I can see something completely different based on this work. slide 6: Smaller Questions Jon - Are we locked into x5u? Is there too much code out there? Probably better to use x5c. Chris, what do you think? Chris - I need more detail. Jon - The JWT can use either x5u or x5c. Chris - The chain is separate? Jon - It would be more syntactically accurate to use x5c to point to that chain. Richard - It's just a value or reference question. The x5c is a literal. On x5u, can you provide multiple certificates in the response? I think it is the case. Jon - I thought it worked. Mary - I like the x5c. We're discussing how to do the chaining in SHAKEN. The x5c gives us desirable properties. Chris is shaking his head. We need to talk about it. Jon - We can say, let's allow either. Jon - Is there value in the "good bit"? Some CAs can do the validation against these databases, others can't. Maybe it would make sense to have a distinction between those CAs. Those that can't do the validation would set the bit to no. Maybe no one ever shouldn't? I hear a vote for that. Chris - I was reading the JWT thing. Jon - Mary was saying she wanted x5c. Russ - I'm concerned that this has turned into an NPAC-centered discussion. We need a solution that will work worldwide. Jon - Yes. These tools will work worldwide. Chris - You can chain or certificate pointed to in both x5u or x5c. Jon - Let's keep x5u for now. Eric - As a validator, I can see that the good bit is good information that I can take into account. But I can also see it as a restraint of trade. Only special people get to be really good CAs. We can discuss on the list whether people would use it, or is it just more lines of code to write? Jon - We don't want to create 2 classes of citizens, and suggest one of them is bad. Richard - If the good bit is false, and the encompassing semantics have not been verified. What is the semantic that the certificate supposed to convey? Jon - It conveys who the parent is, what their OCN is, what has been attested. You might want to make sure it's correct. I can imagine the case where you are doing a sub-delegation from a TN range to another TN range, you can look at it and know. No need to look at an industry database. It wouldn't require setting the good bit for you to be able to trust it on the verifying side. Richard - What would the semantic of the good bit being true be? Jon - The good bit is not relevant to that case, it doesn't need to be set. The good bit would be relevant to its parent, from getting from an OCN to the initial TN range. Mary - You are correct. It increases the confidence. It can add to the analytics. We are building up information of what we know. This isn't as deterministic as you would like. Richard - Usually when an authority signs a certificate, it is saying it has verified it. Here that statement is a one of a collection of facts. Jon - It is merely an input to broader analytics. I would be content to dispense with the evil bit, I mean good bit, and just have the certificates. If a CA is issuing them, it makes sure the encompassing semantics have been validated. It is auditable offline. There are not that many certificates. Chris - Being able to check 2-3-4 different ways is always good thing. Jon - We want to be able to verify in as many ways as we can. We want this to work with as few shenanigans as possible during call setup time. slide 7: Next Steps Jon - Anyone think we're asking the wrong questions? Anything else we should be doing? Martin Dolly - We talked about delegated certificates with our IPPBX lab in Middletown; will they do verification of IPPBX before they connect to our network? They unanimously said hell no. I shared this with IP-NNI, and I am sharing it here. Eric - Why? Martin - In the early 2000s, the IPPBX community was pulling IT functions into the enterprise, then later the pendulum swung, and the enterprises wanted the carrier to do more on their behalf. Today, with cloud, it's moving further away from the enterprise. Our vendors and customers are not going to be doing things like this. In AT&T Flex ... servers our biggest servers, in our database, we have a list of numbers that our customers are using that are AT&T's, numbers that are customers are using that come from another carrier, we added a field for vanity numbers for display. Cullen - I'm confused. I'm the CTO of the largest enterprise vendor of enterprise PBXes, and I know we want this, and we are implementing it, and we want to delegate it. I believe what you are saying, but there is some miscommunication between the two of these. Jon - I have also talked to enterprises and carriers that want to delegate. Some people may not want to delegate, and that's okay. Martin - Cisco was one of the vendors that I was speaking about. Cullen - Martin, I know you heard what you heard. There are people moving more services to the cloud. That's pushing a need for the delegation even more. We could pull information from the vendors and find out what the actual need. Jon (going back to "Why are we talking about this" slide) - The motivation "push credentials from TN owners to an AS able to sign for the call" does not necessarily mean the enterprise will have these delegated certificates. Maybe it's a cloud service or the outbound carrier. Martin, maybe your service will get the delegated credential from Verizon to sign for numbers that are for Verizon's customers, and you'll be the one using it. My greatest fear is an outbound carrier that signs even though they don't own the number with credentials that have no relationship to the ownership that number, and we end up right where we started. We have to get past it. Chris - The 2 use cases I see most are not PBX, but VOIP providers that do not have direct access to TNs and want a solution. We have wholesale customers that support this work. And the other, outbound call centers that want to sign the call and control what's being to shown to their customers. Eric - I would offer that the last two statements [on the slide] are dead wrong; delegated certificates will make it better. When AT&T gives attestation to Fidelity, that's enough for realtime blocking, for penalizing them if they're lying. Making statements that AT&T is going to break -- Jon - I didn't say that. It's fine if AT&T does for Fidelity, but not so great if other carriers with different policies do it. It's a goose/gander problem. From a goose perspective, I don't want to have to do a lot, I just want to sign things. The problem is the verification side once this gets to the gander. This could tank this entire effort. Eric - Is this because of the focus of what is an attestation? Jon - The attestation levels are a factor, but I'm concerned that there is a class of carriers before STIR/SHAKEN came along who were willing to send illegitimate calling party numbers out into the telephone network, that are responsible for impersonation, voicemail hacking, and robo- calling. If we say, "Hey it's okay for carriers to sign for whatever number they want" - with the best intention of having a set of reliable carriers, is that these irresponsible actors will leverage that to continue to impersonate. Except now it will be signed with STIR/SHAKEN, and we've accomplished nothing. Eric - They will find themselves at the wrong end of an enforcement action. Jon - They will in trace-back terms. It will take three months. Eric - It will be a lot faster. That statement is not helpful. Jon - Real-time blocking and authorization have changed the story a bit. Attestation is orthogonal to this. You need the information in real time if you're going to do real-time blocking. Trace back has a different purpose. I don't see the word attestation on here. Eric - Why do you say this doesn't enable real-time blocking? Jon - If the principle you're willing to accept is: "Okay, this was signed for by a carrier, someone who NECA is willing to give these things." Eric - And if that carrier is known to be delivering bad stuff and that number was signed by the carrier, it will get blocked. Jon - I said it was a good start. Eric - That's not a trace back thing, it's a whack the call thing. Jon - It's a real-time after trace back. Richard - Your assumption is that there some service who will tell me who the bad OCNs are, bad carriers. Someone's has get on that list first, then they can be subject to real-time enforcement. Jon - And that is based on a pattern of bad behavior. Richard - There is validation of the control of the assets upfront. Someone cannot sign something they do not own. Jon - Even better. Good start does not mean that it does not work. Ted Hardy - In other carriers, one of the issues is that it is relatively easy for somebody who wishes to behave as a gander to mint a new identity, and become a gander over and over again with new identities. This occurs in spam and impersonation, it occurs other places. Jon - This is question of how Newco works, and how you get OCNs. Ted - Is there a way for somebody who has previously been given an OCN, which has ended up on this list, to be traced to future applications to the same authority or not? If the answer is no, then you are setting up a periodicity that's related -- Jon - I get it. It isn't quick, but there's are a lot of them out there. Some people may have opportunity to cycle through them rapidly, but it's a relatively constrained resource. They're relatively difficult to get. There could be analytics that could let you make correlations, but it's tricky. Ted - In this case, since the OCN is relatively difficult to get, the threat model is whether the burden of creating a new OCN is met by the financial gain of being willing to be the originator of this sort of traffic. We could figure out where that break point is. That turns the question into whether the better situation where you never have to go through this 15 minutes already. You never have to do this OCN lookup at all. Is it worth the the additional effort and money that will go in to enabling these other use cases? There's a risk here, which is not the same risk we see in environments where they're freely minting identities. It is not clear how that risk/reward will match once this is very common. Jon - There are more wrinkles. Pseudo OCNs, like SPCs that are not quite OCNs, could have very different properties in terms of how they acquire them and how quickly they can be correlated. There's a lot of edges that we'd need to analyze. I was not trying to pick a fight with this, and I apologize if the way I put it was divisive. Mary - The overhead of getting another OCN won't be worth the effort. Jon - But if it's a pseudo OCN -- Mary - They have to go through the rigamarole of setting up an account with the PA. Jon - Depends on how they are issued. If it depends on the PA to issue them. Robert - We are out of time. We will set up a virtual interim in early September. I'll send out a poll. ACTION: Robert to send a poll for virtual interim meeting in September. Russ - Let's keep the discussion going on the list. [ End of meeting; ran out of time. ] [ Agenda topics for draft-ietf-stir-passport-rcd and updates on post-WGLC ] [ documents draft-ietf-stir-oob and draft-ietf-stir-passport-divert were ] [ not covered. ]