Re: [stir] stir 93 meeting minutes

Edits inline

-----Original Message-----
From: stir [mailto:stir-bounces@ietf.org] On Behalf Of A. Jean Mahoney
Sent: Monday, July 20, 2015 2:02 PM
To: stir@ietf.org
Subject: [stir] stir 93 meeting minutes

Hi all,

My notes from the meeting below. Ellipses (...) mark places where I didn't catch what was said. Feel free to fill in.

Thanks,

Jean

Secure Telephone Identity Revisited (STIR) IETF 93 Session 2015-07-20 1520-1720: Karlin III

10m Administrative  - Chairs
Presentation: 
https://www.ietf.org/proceedings/93/slides/slides-93-stir-2.pdf
Presenters: Robert Sparks, Russ Housley

Jabber scribe: Pete Resnick
Jabber archive: http://www.ietf.org/jabber/logs/stir/2015-07-20.html
Note taker: Jean Mahoney

Slides presented. Note Well noted, no changes to the agenda.

50m draft-ietf-stir-rfc4474bis-04
Document: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis
Presentation: 
https://www.ietf.org/proceedings/93/slides/slides-93-stir-0.pdf
Presenter: Jon Peterson

slide 1: Title

slide 2: What we did since -03

slide 3: Open Issues: Signing PAI

"canon" is an optimization, it captures how the signer saw it. Helpful for debugging.
Can assume that everyone within a Trust domain can do the canonicalization. PAI is stripped when leaving the trust domain, but what about 'canon' - maybe the gateway wouldn't remove it. This is noted in the draft text. What's the value of the signature in a closed, trusted network?

Martin Dolly: Not quite true that PAI only originate in a TD. We receive them over other interfaces. Having a verification mechanism and sign it... Enterprises today will send a PAI to the carrier. We process on customer subscriber ID, we don't look at it. For a North Am deployment that the enterprise could use that number, and the basis for the carrier signing it.
>>mcd begin
 .... having a verification mechanism and signing the PAI is the only way to guarantee verification. ...... For a North American deployment, the carrier could validate that the enterprise is allowed to use the number in the PAI (network verification in ISUP/ISDN terms) and sign it.
>>>mcd end

Jon: Do we need to revisit 3325? Kill me if we do. It's the edge element's responsibility to ... and promulgate it through the trust domain.  I'm skeptical that's the motivation.

Brian Rosen: It /might/ be acceptable to write text that the PAI is there... If the person doesn't put in the right From, the call will fail.

Jon: ... I'm not going to recommend it - there are problems

Brian: Even if they don't put the canon in, if it doesn't match what is in the From, it's ok. The originator didn't do it right, or a middle box didn't do it right, and it will fail.

Jon: and that's ok.

Henning: Schulzrinne: PAI does cross boundaries across the carriers - SIP Forum/ATIS document.

Jon: This is what Mark Watson was imagining when he wrote RFC3324. The SIP networks would behave like the PSTN.

Martin: If you look at spoof and robocalling, they're typically from smaller carriers. ATT doesn't trust those carriers like it trusts Verizon, but we have to interwork with them. It was said on the list a few times - we cannot just drop calls, we are legally obligated.
>Mcd begin:
....we are legally obligated to complete them.
>MCD end

Brian: Ok, verification might fail. I didn't say drop.

Jon: how do verify...

Martin: If we are going to deploy on signing certain parts of the messages that are validated at the end. To address reality - you have to sign PAI.

Jon: It lets you sign PAI today.

Henning: The brief privacy discussion we had earlier on the list today. 
Anonymity is really pseudo-anonymity. The carrier knows, but not the recipient. The current model - use the standard anonymity in the From header and keep the PAI. We need to distinguish because they are different services. Particularly, if you have anonymous calls, you should sign. Needs to be default behavior.

Jon: we can add motivating text to explain when you want to make the tradeoff. There's privacy leakage. Implementations have to be mindful, and shouldn't hurt anybody.

Robin Wilton: There's another use case - I have a portable, 3rd party number and I give it to other people. It breaks for a couple reasons, like because the receiver won't accept tariff uplift. It might break here.

Jon: I think we have a story for this. NNI use cases that use PAI, would be good to know.

slide 4: Signing anything else

Jon: CNIT - how to implement? I swore I wouldn't do it, but I've defined a blank-check extension header for future proofing - Identity-Extension. 
Need to have strict IANA controls on it - standards action and enough review.

Henning: We have 2 mechanisms - Identity-Extension and identity-reliance mechanisms. Getting cozy with each other. These are exceptional mechanisms and will be widely deployed. The more we unify these concepts. Take URI, make it part of the signature. One can fail, one can succeed. Part of the motivating design - organized and single way. 
Concern about current draft - multiple signing authorities - enterprises and carrier. We need to look at the permutations.

Jon: valid concerns. I allow 1 extension per request. Becomes a LOA, and the decisions become more complex.

Henning: It should not be a kitchen sink. Don't object to raising the bar. What's the operational model? How do you fingerprint it? How to canonicalize it? Do you expect hard or soft failure? There's enough stuff to be specified... I prefer a single, extensible mechanism rather than three. Identity-Extension is not a good sign.

Jon: It can be done. We have 3 things that are one-off mechanisms, may or may not be in the signing. Secure RTP - not always present. 
Identity-Reliance - can sign the entire message. Henning is saying that I should just generalize, and it will look like DKIM. I can live with that, but I swore I would not do DKIM. I want it to be clear - is it trustable?

Henning: From the code perspective: it doesn't matter. I think we're close enough to convergence. It's easier to separate out things that ATIS will worry about immediately versus long term.

Pete Resnick: Make sure the Identity-Extension is signed.

Jon: The Identity header ensures the it's signed. Make all the options a Identity-Extension, and a path to extend it.

Henning: Need to be aware of 2 models - single entity doing a lot of sigs. We want to downgrade attacks. You have 2 entities that are doing the signing. Depending on the ordering, may happen before CNAM signing. 
For instance, Carrier signs it, hands it to Dunn & Bradstreet, who verifies that it's from this bank and signs it. The signature is always the last one. Need to be aware of it. The master signer is the one that adds the Identity header.

Jon: I was going to argue that the CNIT was the .. Signed by.. I want the trust to be end-to-end. To get the property - have its own signer. 
being argued in CNIT.

Robert Sparks: as you make the changes, what pitfalls do we need to avoid its looking DKIM-y?

Jon: standards action.

Robert: anyone object?

Alyssa Cooper: You could make it more burdensome - have to address how it will interact with what is already there.

Jon: we can create a template - what you have to do. I'm good.

slide 5: Eric's Comments

Robin: The authentication service must authenticate - why did Eric make that comment?

Jon: Eric thinks that an authentication service is a intermediary. But there is no bar, the auth service could be in the endpoint.

Robin: conflation of ... if you hand out credentials, but if you haven't authenticated. We can help disambiguate.

Eric Burger (in the jabber room, relayed via Pete): the difference is what we know versus a non-IETF implementor. I'm sure the people who wrote the PATRIOT Act had no idea it would be used to spy on Americans, for example. Yes, the draft has a sentence about the service can be in the SIP UA. It then has paragraphs on a separate service. If you did not listen to this discussion (and who does), what would you think if you were an implementor?  I think we should explicitly describe the three major  deployment models: In the SIP UAC, By the service provider
(P-CSCF/SBC) or Enterprise (IP PBX), and a third-party service bureau (as Henning *just* said).

Jon: I'm content to say "end points" and "intermediaries", and these elements understand their logical roles.

Henning: I agree. SIP forum and ATIS can explain how to use it in their environments as long as the models aren't being excluded. These extensions are presented in the draft like characters in a novel. Can cover the extensions in the overview. That would address the functional flexibility.

Eric: Agree

Jon: Good suggestion.

slide 6: Next Steps?

Jon: As identified here - Identity-Extension to subsume the fingerprint and reliance mechanisms.

Brian: I raised the issue about # and *.

Robert: When will this get done? There are environmental pressures to finish. Will there be spin and talk in Yokohama, or a LC before late September?

Jon: Let's try to do it by September.

Henning: People can send text to help out.

Jon: definitely. There's going to be surgery on this draft.

4:06 60m draft-ietf-stir-certificates-02 - Jon Peterson
Document: https://datatracker.ietf.org/doc/draft-ietf-stir-certificates

slide 1: Title

slide 2: What we did since -01

Martin: I don't see where this is needed. Authorities assign TNs to companies that they can punish. If you sign this, it's traceable. If you didn't do it correctly, you can be punished. I don't think this mandatory.

Jon: We're trying to detect threats. The certs could be delegated, maybe to small enterprises or end users. They can sign from their own end points.

Henning: I don't understand the difference between sign it and - signed by number allocated, then signed by ATT, delegated down to a PBX company -

Jon: that's one model. For ATT it isn't useful to list numbers. ATT and Verizon trust each other.

Henning: They could create a custom cert for each number.

Jon: Or they can have 1 cert for every number they own.

Paul Kyzivat from Jabber room via Pete: For UAS to be able to authenticate, the cert and TNAuthList must be accessible to any UAS. Any plan to require that?

Jon: if it is present, it's part of the cert. They have this TNAuthList.

slide 3: Why OCSP? (Refresher)

Eric: Even if we agree to the presentation today, and I will be the first to say that I may have *totally* misunderstood the Certs draft, but if someone with just half a clue can totally misunderstand the draft (and I don't think I did), then someone with a quarter clue will be totally lost. And, I agree with others, I still do not see the merits of knowing whether or not someone is authorized to sign for a number.

Jon: Can we pull up the charter - the point is to know if someone is authenticated to use the number.

Martin: ATT authenticates and validates that the phone can use that phone number, ATT doesn't know if its actually _you_. ATT says this phone can use this number.

Jon: That's exactly the mechanism.

Brian: and it they want to, they can have just one cert for every number.

Chairs pulled up the charter: The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call.

Martin: The solution doesn't need to include TNs in the cert. You need to validate the cert.

Jon: If I can get to the slide that describes this.

slide 4: In-band STIR Logical Architecture

Henning: Every student in computer science knows that any problem can be solved by adding another level of indirection. We're trying to avoid a per-number cert.

Jon: But we will allow it.

Henning: The number of network transits

Jon: have whole slide. From an efficiency perspective. OCSP is not required.

Henning: The more mechanisms we add, on the validation side, you have to support all of them. I'm worried that the more mechanisms, the higher the burden on the receiver. We've just added complexity without adding value.

Jon: I think we should go the slides

Richard Barnes: you should do OCSP anyway - then 0 cost.

Jon: can download via URL.

Eric: I do not want to let the statement "The charter says we MUST have a cert mechanism to carry TNs" go unchallenged. That is factually incorrect.

Paul: if I get a cert not from ATT, but from acme-telco.net signing a number, if I can't get evidence that it is entitled to sign for the number, then why would I trust it?

Pete, to Eric: Nobody is saying that the cert has to carry the TN AFAICT. Who did?

Eric: The alternative in the draft is you poll at a transaction rate of
100,000 tps for a typical U.S. busy hour to ask someone else if the cert covers the TN. Not a realistic model. So it is not the issue of carrying the TN, but that anyone cares about the TN at all. (TN in the or covered by the cert. Of course, the whole point is validating the TN)

Jon: I think we should take the discussion to the list. At a high level, it won't matter to you. But it's to support use cases, that the cert is associated to TN. This charter is not of use for you.

Brian: 100k/hour or minute is no big deal. We can do that.

slide 5: RFC5019 vs RFC6960

Richard: This thing shouldn't impact scalability of RFC5019

Paul:  if the usage model becomes one of recipients trusting certain signers, then users will be forced to get their numbers from a widely trusted provider.

Jon: Don't think so - there will be a proper chain of delegation

Robin: There's a level of confusion - who is trusting what, how is it exchanged? TN vs not-TN, what's it mean?

Jon: we say what goes on the wire, you make the decision of what to do. 
If there's interest in specifying the policy decisions. As the bis draft becomes more DKIM-like.

slide 6: Our Extension: TNQuery

Jon: Sean and I talked this over. Seemed OK. Russ? Russ is not barfing. 
Don't want an "unknown" response, it has hard edges.

Richard: the optimization that 5019 gives you is based on "unknown". If 
a cert is expired, you don't have to keep it. It lets you pre-generate 
responses.

Russ: There's also a serial number that hasn't been issued.

Richard: The only thing you say yes on - are things that are valid. 
Things expired or not issued - it's unknown. The cert is "unknown".

Jon: I don't trust it. Why have even have "unknown"?

Henning: One reason - for caching. If you receive a no, the cert won't 
get more valid with time. If you get an "unknown" - you might try again. 
I have a question about the mechanism - a validator would separate into 
- carriers will sell you a cert and say OCSP.

Jon: You have to check the OCSP - see the chain.

Russ Housley: OCSP responses - good, bad, unknown - the only one you are 
interested in is good. We are adding - does it apply to the number? If 
the cert is good, you get yes or no on that question.

Pete: I'm checking with the chair - go with a whitelist?

Brian: in every formal system, there are always informal systems.

Jon: Premise is false - the carriers don't know each other's numbers. 
And get upset if another carrier finds out.

Jon: what do we do with "unknown"?

Russ: treat it as "no"

???: treat it as "no"

Jon: done

Robert: RTFM

slide 7: TNQuery (2): Open Questions

Richard: it doesn't seem critical, you get the ... Allow multiple TNs in 
the request, it has a privacy benefit. Don't put it in the response. 
Like fuzzing in geopriv.

Robert: you can't say yes for some.

Jon: you can glom OCSP into one request.

Richard: check the RFC.

Robert: Since i haven't read the RFCs in quite some time, can you 
include more numbers in the response than in the request?

Richard: yes. you can cache by chunk.

Jon: yes

slide 8: TNQuery (3): Why do you ask?

Jon: would like to tie the request to a call. To avoid impersonators and 
spidering.

Richard: the attacker can't ask for any number. Has to be in the scope 
of the cert. They can segment the space.

Jon: But if Martin wants to be lazy, I don't want to prevent that. It's 
only fair, what he gives me on the list.

Henning: you have to have a small number - a cert for an area code 
doesn't help a whole lot. I don't think dividing the space will help.

Martin: if you allow for one cert per carrier. ok.

Jon: do we think this is a problem? We can work on it.

slide 9: Fancy Measures

Robert (from floor): reacting or overreacting to this in real time - 
I'll restate what I heard. CA gives a secret to the caller. The hash is 
included in the request and the hash has

Jon: TN is part of it with the nonce.

Robert: why restrict it to the TN? OCSP server digests the hash. Could 
you bury the ranges in the hash?

Richard: (off mic)

Russ: it certainly interferes with this.

Robert: this is getting weedy.

Jon: ...

Richard: The entire point to add numbers was to provide chaff.

Jon: This is the only promising path.

Richard: not very promising.

Pete: anyone want to do this?

Martin: No!

Pete: Suggestion - let's not do this, and see who yelps. There are other 
ways of doing this.

Richard: I think the answer is no. To put one more knife in this, don't 
you need the signer online to do this nonce-y thing?

Jon: this is an idea that Sean and I had at the bar yesterday.

Russ: I want to see that napkin.

Jon: This is not in the draft, and if people don't want to work on this, 
that's ok.

slide 10: Acquiring TNAuthList By Reference

Henning: who would return?

Jon: Cisco PBX with 1k numbers.

Henning: a carrier that owns 50M numbers. These numbers are going to be 
onsies and twosies because of ports. If the cert says I'm a carrier. If 
I have to ask the LNPA, that changes by the minute and will be outdated 
when I get it.

Jon: 2 cases - root of trust issues every cert. ATT goes to that 
authority to ask on behalf of the entity. The root give it to the 
entity. Or ATT can delegate. All these certs exist still. The chain will 
say if that part of the chain had authority.

Jon: issued by ATT for a larger share.

Henning: list of 50M random numbers.

Jon: all that matters - what's been delegated is a part of the ATT list.

Henning: if I'm a validator, and I don't know the small carrier, and I 
go to the OCSP server.

Jonathan Lennox: Say I'm mafia telecom, and I control the OCSP server. 
It has to be who delegated to mafia telecom.

Jon: 2 ways - go to LNPA or go to the carrier. There's always the guy 
above you. You didn't self-sign the cert.

Lennox: what about multiple delegated chains? I have to validate every 
step in chain.

Jon: yes.

Sean Turner: you have to go up the path, but you can cache. You can send 
more than one request per query.

Richard: I'll throw out a idea in realtime - live OCSP to resolve - 
prefer not to do this for web. OCSP stapling. In addition to cert you 
get a signed blob.

Jon: you put the burden on the sender.

Richard: need to take the idea to the list.

Jon: the signer choses what the validation is. The validator can't ask 
about random numbers. The way to spider is one call per number. The 
stapling occurs during call.

Robin: this heading in a direction of a problem in the web PKI world, 
where there are multiple chains of authority

Jon: there's a single for each country.

Robin: good.

Martin: needs to be simple. Are you still going to have spoof calls? 
Yes. Circuit calls will continue, and they won't be validated. If you 
are going to make it better, but not solved.

Chris Wendt: A while ago I advocated a grouping model. I'm moving to a 
one cert per number model.

Henning: We have 3 mechanisms - caching, OCSP, and this mechanism. What 
I'm missing is an estimate on real scenarios - typical interaction. 
Deployability is the biggest concern. How would OCSP work? If something 
got invalidated 10 seconds ago? Who needs to talk to whom?

Jon: We are designing tools, we're not designing architecture. This is 
the first time we're discussing this.

Henning: a set of roughly common test cases. Long before ATIS gets it. 
We need to have a common understanding about who does what to whom. 
Trying to make it efficient.

Jon: this is new stuff. OCSP changes everything. We're still looking at 
design space.

Eric: And then we are back to the entity issuing the cert attesting they 
are authorized to issue the cert. In the real world, that is good enough 
because as Martin says, they can be punished. It also highlights why no 
one will care whether or not someone is allowed to sign for a particular 
TN, or block of TNs. Punishment is good enough. And then the Mafia goes 
to jail. Bad for a day, but then the problem gets fixed for at least 10 
years. (10 years when they are in jail)

Jon: no comment

Pete: Joe Blow telecom gets a query regarding a call. Joe Blow telecom 
lies about owning the number. As a validator, I received a response from 
ATT about the number, but I won't get the answer that joe blow telecom 
is nonsense.

Jon: you won't get to the OCSP server if Joe is self-signing

Lennox: What's the difference between stapled response and a ...

Jon: ...

Lennox: why would I want multiple?

Richard: tiny response and answer, versus big answer.

Lennox: what's the benefit of big certs? It seems better to be per TN.

Jon: I suspect that carriers want certs for blocks.

Sean: we bring DOS up. But there are other things to worry about.

Brian: create a couple of use cases and work it out.

Chris: Good suggestion.

Jon: the big certs are for big carriers.

Robert: We are out of time.

Jon: I got a lot of good feedback.

Robert: there are lot of comfy couches and hallways here. Have 
conversations.

Russ: Take it to the list.

Rest of slides skipped:

slide 11: Future Work: Subscriptions

slide 12: Other Open Issues

slide 13: Eric's Comments

slide 14: Next Steps

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir