[stir] stir 93 meeting minutes

["A. Jean Mahoney" <[e-mail]>]

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.

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.

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