IETF97 - Secure Telephone Identity Revisited (STIR) Minutes Summary: draft-ietf-stir-rfc4474bis, draft-ietf-stir-passport, and draft-ietf-stir-certificates are in IESG Evaluation, and a few discuss positions have been entered. The group briefly discussed the most significant changes likely to be made to resolve the discuss positions for the stir-certificates document. There was strong consensus in the room to add PASSporT extensions and using ACME for STIR certificate enrollment to the working group's charter. Proposed charter text will be sent to the working group mail list shortly after the meeting. Raw notes taken by Jean Mahoney during the STIR WG session follow. ======================================================================== STIR - IETF97 Wednesday 0930-1100 -------------------------------------------------------------------- 0930 ( 5m) : Administrivia (chairs) Note taker: Jean Mahoney Jabber scribe: Matt Miller slide 1: Title slide 2: Note Well slide 3: Agenda Russ Housley - No changes to the agenda. -------------------------------------------------------------------- 0935 (10m) : Status of rfc4474bis, passport, certificates (chairs) draft-ietf-stir-rfc4474bis draft-ietf-stir-passport draft-ietf-stir-certificates Robert Sparks - All in a position of discuss clearing. probably won't come back to the WG. Jon Peterson - Steven had a large issues list on the certs draft. Can work through it. The main one is the PERPASS implications for the OCSP validation of TNs. Parties for realtime validation would be sending over the wire the question: Is the cert valid for the number?The answer is unfortunately sent in the clear. We will roll back the strength of the recommendation. Look at other cert strategies - short-lived certs. We may kinda punt on this. The certs document will cover some strategies but won't recommend OCSP like we did. Any issues? Russ Housley - There's another aspect to this - Either the Security Considerations section is going to explain or there will be a new Privacy Considerations. Jon - We will call out the issue. I'm inclined to roll back the recommendation, and describe a couple of ways to do it. We'll need to experiment before realtime validation before making a strong recommendation. Russ - I agree, but about short-lived certs - if they are short lived enough, you don't need to any revocation checking, you include the no rev check extension. Jon - I'll talk about it in the stir with acme presentation. Eric Rescorla - short-lived certs are a viable option. The current OSCP design - OSCP server is an oracle that maps SPIDs to TNs. If you are going to map the cert system, you need something acme. I have a credential that authorizes that that SPID. When I need it I get a cert that validates the TN not the SPID. Otherwise there's not way to validate the SPID. Need a separate SPID resolution mechanism. Jon - a separate SPID resolution mechanism for SPID to TN. Nothing in the doc says that you have to perform that check. We can find an oracle that can do that translation. ekr - for those not familiar with SS7, if you could provide a layout of what those options are. -------------------------------------------------------------------- 0945 (35m) : Out-of-band (Jon Peterson) draft-rescorla-stir-fallback slide 1: Title slide 2: Thread necromancy slide 3: Do we still need it? slide 4: Limits of in-band RFC4474bis slide 5: PASSporT and out-of-band slide 6: SOME USE CASES slide 7: Basic STIR Out of Band slide 8: Obvious Questions Jon - If you squint at it, looks like VIPR. VIPR had problems. There's a DHT way of doing it, locate CPSes. LoST, DNS. Lot of options. Don't need to standardize just one as the One True Way. slide 9: Components of an OOB solution slide 10: Another Case: IP-PSTN Gateways slide 11: and its many cousins... slide 12: IP-PSTN-IP even? Sure! Jon - SS7 indicator doesn't handle this very well. slide 13: Well, let's not get carried away Jon - Doesn't matter to the CPS who stores the information. It just looks at the passport itself, is it valid. Chris Wendt - You want to limit writing, but need to be open from a reading perspective. The problem with the passport object has all CDRs in it. Jon - this depends on your key for retrieving CPS. Eric Burger (remote) - MIC: except for providing an easy point for pervasive metadata monitoring, why do we require a CPS instead of an end-to-end transfer of the PASSportT token, where we can use all of the IETF end-to-end integrity mechanisms to (1) deliver the token and (2) ensure its integrity? Jon - This is for cases where there is not an e2e IP connection between the authentication service and verification service. Jonathan Lennox - how to protect the CPS from being a PERPASS target. Jon - I don't have a complete solution. When you connect to CPS as a verification service for a passport, and ask are there any passports from this originating number? TLS and login for protection before you can access passports. You will need to prove that you are the right target for a call from that number. May not be sufficient - looking at using some kind of hash of originating and terminating number, but not sufficient because you could calculate those hashes, for say Lady Gaga calling Madonna, and poll for whether the call is made. Need polling prevention. We can't carry a nonce. Have to assume a discontinuity. Only have these 3 factors - originating number, terminating number and timestamp. We have the ability to prove that you are the authority for a set of numbers. Those are the moving pieces. Henning - To frame the requirements from privacy perspective, we should be no more or no less strict than who can access CDRs? The originating, intermediate carriers, terminating carriers. Protecting beyond that is pointless. Assuming CPS security isn't any less that CDR security. Authenticate the terminating entity equally strong and use the same trust relationship with their carrier. They don't know originating carrier. If it gets deposited in the terminating carrier's CPS. The customer has an oauth token... a range of authentication mechanisms, strong or weak, individual or corporate. That transforms the problem for the model - the originating entity has to find the terminating carrier and we know how to do that. Jon - if we could do that, could do e2e SIP. Henning - a db will give you good approximation of terminating carrier. Or an entity that has a contractual relationship with terminating carrier, like a SIP trunking service. get numbers through 3rd party, like Level3, holder of record for the terminating number. Jon - the use of certs for STIR to prove that you have the authority for the number can take place of the trust relationship that you described, and allow the CPS to be decoupled from the admin of either the originating or terminating carrier. Worth considering. Henning - If I can compromise the CPS, I have problem. Jon - Credentials can be encrypted then, right? Henning - If the passport can be encrypted ...by opaque hash. credentials can be used for ... Jon - it's indexed at the CPS by the hash, that's different than saying the passport contains a hash. The passport can be encrypted with an opaque hash. If you have credentials allow you to assert ownership of a number they can be used for encryption as well. Robert - back up to "Sure!" slide. You fundamental premise that you use the CPS when there is no direct internet connection, but that's flawed. You could gateway to a protocol that can't carry the information even if you have an internet connection between endpoints. Jon - I said that there could be IP. Just stripping identity headers could be a problem. RjS - that CPS is a logical role could live in an endpoints. The e2e transport security that Eric was talking about could be applied. It's a unique use case. an edge. Don't preclude that. Jon - agree Jonathan - assumption - signer and verifier have internet access. Why would the CPS hold the passport at all, the CPS could just be a rendezvous service. Jon - I'm looking for general framework that would also work for, say, XMPP to SIP. Jonathan - I would like to minimize the info the CPS has. Could be a rendezvous point. Rather than big database of every call on the net. Jon - Having the records encrypted at the CPS will be part of the design. I'm not trying to create a backchannel to negotiate SIP or something else, against the wishes of the things in the middle. Just give me the passport. The passport won't give you mlines. Jonathan - There are use cases where I don't have bandwidth for voice call but can pass 1k data around. Jon - On the IP-PSTN GW slide, it's a pots call that's come in. If we had a rendezvous function, could set up the SIP call and drop the pots. Jonathan - I don't want to set up a SIP call. OK I'm doing audio over pots for a reason, It doesn't mean that the information passing has to be store and retrieval. Jon - agree that the CPS could be a place to get a pointer to the passport. Cullen - what info do we use that access this pointer, and pointer may not buy you anything. VIPR - can have useful IP path but they go over PTSN anyway. Important problem to solve. Dave Crocker from Jabber room - Mic: If there is standardized naming of the actors, there needn't even be a rendezvous function, since the passport could be stored in the DNS under that (domain) name. Jon - Storing in DNS, it's not off the table. DNS would contain pointers. These are short lived. Just for the duration of the call's alerting. Not sure best fit. ekr - Is something like this valuable? I think yes. Is it implementable in a way that is acceptable? That's a question. I've worked on this design but I'm not happy with it. Point of exploring this. slide 14: CPS Design Questions slide 15: Next steps Jon - we don't have this licked. Let's do some work. We have part of the PTSN story in ATIS. This part will get a few more kinds of endpoints participating in the STIR ecosystem. 44:13 - (lose audio here) Henning - Be open to a variety of architectures. Base CPS storage. Carrier storage. Jon - I'm not saying that they don't work. My concern with carriers - you can perform the rendezvous. Henning - We have a coordination problem - interoperability, certificate ..., entities in the middle and edges. The endpoints can do things on their own, but advocates for solutions that can be deployed with minimal coordination. (get back - 47 m) Jon - There's nothing about this that says CPS is monolithic or centralized. It's logical. Have no problem with that. Cullen - we have lots of IP-IP networks. Even if it's all IP - deal with it on the edges don't have to upgrade the stuff in the middle. Ekr - I don't think storing it in the endpoints won't work well. The CPS will be in the cloud somehow. Jon - and what is in the cloud may just be a pointer. but we only have the 3 factors and they must give you the same answer on where you go get this. Henning - we have 3 piece of info, but also have existing databases that allow us to do the mapping. Can rely on external infrastructure in some cases. Jon - I don't have an ask about this today. There will probably be a virtual interim meeting next year. -------------------------------------------------------------------- 1020 (20m) : Passport Extensions (Jon Peterson, Chris Wendt) draft-peterson-stir-cnam slide 1: Title slide 2: Twofold PASSporT extensibility model Jon - We've changed passport a lot in the last 4 months. Jonathan - I'm confused by this slide - sub-bullets look identical. Jon - geez, you're right. slide 3: Demonstrating extensibility slide 4: draft-peterson-passport-divert-00 Jon - didn't we publish diversion as an historic RFC? Cullen - after being published on Cisco's website for 10 years, it finally got it published. Christer - discussions of History-info - is it a retarget or just diversion? Can you use for retarget or rerouting? Can you differentiate? Jon - Canonicalization removes things in URI, but that doesn't change the dest. Don't need new passport. Mary - I need to think about it some more. Jon - this is new. This is a proposal for extending passport. Mary - I can see how this can work, but there will be duplicated info. Chris - this mirrors history-info. Jon - yes, what's in div is what is in history-info, but it's crypto signed. We talked about signing history-info but we decided not to. Mary - we have tools now to sign. Jon - this is a -00, this is an example of what we could do after a recharter. Alan Ford - I appreciate this as a example. It's confusing having a single domain. Let's say the domain is example2, does example2 sign both, are there are two identity headers? Jon - div is signed with credential for the original destination not originator. Extensibility model lets us do this so long as ppt is mandatory. Alan - need 2 identity headers then? Jon - yes. Alan - it seems like it would work. Jon - Yes, it's different from History-Info because of the canonicalization, it doesn't capture reasons. Once you create an extension you could create a bucket to hold other things like reasons. Chris - When you go hop-by-hop, you would add to history-info, and an identity header for in-band. Jon - works differently in out of band. In band and if you have History-Info, you can walk back and find out if it should have been sent to you. Chris - you have this div ppt. with original identity header, another one for div. Jon - right. Canonicalization would eliminate some minor things that are tracked by history-info. I'm just trying showing that the extensibility property would work. slide 5: Inverting the usual rule slide 6: For an original PASSporT... slide 7: "div" with "ppt" slide 8: draft-peterson-stir-cnam-01 Jonathan - something in the root cert saying that I'm willing to sign cnams. If I get a cert for my phone number and I prove it's my phone number, then send you a passport saying Jon Peterson, that's pretty bad. Jon - proof of possession certs have a different LOA. We have to talk about it. Those certs will have different powers. Jonathan - VZW gives me a cert that says I own this phone number. there needs to be something in the cert that says that you are allowed to sign it. Jon - if you look at stir-certs, Russ added a JWT claim constraint. If this claim is in the passport it has to have this value or don't accept it. slide 9: "cna" without "ppt" slide 10: "cna" with "ppt" slide 11: Elaborating on "cna" Alan - if the receiver couldn't validate, is it up to local policy, does it fail? Jon - up to local policy. The draft's a sketch. Within the CNA something else appears, there's no provision that it has to fail. Alan - if you don't define ppt then it's local policy. Jon - yes. slide 12: Sanity checking Henning - Reducing general confusion - using the term "cnam" itself, it implies a name and a db lookup mechanism. This is not cnam - It's not subject to the same restrictions and doesn't originate from the same databases. It's call info largely plus the display name. Jon - it's a secure call info. Christer - there could be a case where there's multiple ppt values in a passport. div with something else. Jon - I don't think div would ever be together with something else. You have 2 identity headers if you have two things. Let me know if it's not clear in the spec. Alternatives look bad. Alan - if you have multiple identity headers, someone can remove one of them. Someone could edit the called name. Jon - Yes, they can remove the identity header. No one can edit the called name. Chris - in practical deployments, you will have a ppt itself or just add certain claims, not 12 identity headers just for the heck of it. ekr - I think it's unwise to have multiple identity headers. Have it be parallel. Trying to harmonize the view fails cryptographically. Russ may disagree. Russ - No, when there's multiple signatures, you don't know which to validate. Jonathan - make it clear to the cert issuers that they need to think about future, unknown claim extensions when making their certs. Need claim constraints - I can only sign baseline. Russ - we did not define a wildcard for claims. So if that's important - We didn't say can't include *. Jonathan - There needs to be guidance saying - think about extensibility of signing claims. Russ - agree Jon - we still have work to do. Chris - It's the opposite problem - you need to trust the person that you are validating, local policy should be to ignore claims that you don't want to receive or can't understand. You can say don't trust. -------------------------------------------------------------------- 1040 (10m) : Using STIR with ACME (Jon Peterson) draft-peterson-acme-telephone slide 1: Title slide 2: ACME slide 3: STIR and ACME slide 4: ACME (through a STIR lens) slide 5: What are interesting proofs? slide 6: Fancy applications slide 7: Next steps Mary - this is interesting and we should pursue it, we're looking at this in the NNI taskforce. We should work together on this. Simon - I like this, would implement. Rich Salz - I'm co-chair of acme. There are long-lived certs that can live in the sim. acme will be LC soon but is extensible. this is cool. Certs for phones will swamp CAs. Chris - support this as well. In addition to IPNNI work, we're making this compatible with service provider certs and moving to TNs. Think there is a path there. Danny McCarney, Let's Encrypt - having a use case like this will help the acme WG for clarifying whether we have the right things in that aren't DNS identifiers. Cullen - very supportive and happy to contribute. Matt Miller - Eric burger is also supportive. Jon - We're not chartered to do this. I propose a general charter slot for extensions. I would like something like this - something to explore cert management. Chris - +1 for extensions Ben - For extension item for charter would you expect work discussed in SIPBRANDY, DISPATCH would be don't here. Jon - I don't think sipbrandy work needs to be done here. I don't want to create a constraint that the work must be done here. Martin Dolly - Add an RPH example. Jon - got it. -------------------------------------------------------------------- 1050 (10m) : Charter checkpoint - recharter? (chairs) Robert, as chair - I would like a show of hands of people who are willing to work on passport extensions, and are willing to review them, and think this is the appropriate venue to do so? [Lots of hands in the room] Robert, as chair - I would like a show of hands from people who want to work on integrating stir and acme and think this is the appropriate venue to do so. [Lots of hands in the room] RjS - I think that's sufficient support to show that we have energy. We'll work out proposed charter text with ADs, and post text to the list shortly after the meeting. Russ - we are out of time.