Minutes IETF99: stir
minutes-99-stir-00

Meeting Minutes Secure Telephone Identity Revisited (stir) WG
Title Minutes IETF99: stir
State Active
Other versions plain text
Last updated 2017-08-01

Meeting Minutes
minutes-99-stir

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.