* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Stir Status Pages

Secure Telephone Identity Revisited (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2013-Aug-30 —  

IETF-99 stir minutes

Session 2017-07-19 1330-1500: Karlin I/II - Audio stream - stir chatroom


minutes-99-stir-00 minute

          Secure Telephone Identity Revisited (stir) - IETF 99 - Prague
          19 July, 2017 : 1330-1500 - Karlin I/II
          * draft-wendt-stir-passport-shaken needs more reviewers
          * draft-ietf-stir-rph will be revised reflecting comments to date. We
            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
            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)
          slide 1: Title
          slide 2: SHAKEN PASSporT extension - Attestation and Originating
          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 )
          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
          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
          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 )
          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
          Jon: Is there a threat model here where somebody will create bogus
          History-Info simultaneously with being able to sign for these divert
          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
          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
          it - don't sign it. Apply the same metric here.
          Martin Dolly:  we have use case - Financial institutions' IVRs that
          calls to desks.
          Russ: To clarify, Martin, yes, you want divert. Do you want the Reason
          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
          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,
          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 )
          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
          is the responsible entity. They have an OCN in which that number lives,
          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
          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
          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
          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
          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
          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
          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
          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
          use case, you must do these things and follow these policies if you're
          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
          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
          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
          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
          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
          carrier is the source.
          Paul: there's going to be reputation scores for the parties. The 3rd
          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
          so that means that number has been determined to be authoritatively
          to that caller. Add text to make sure that no implementor will make that
          Jon: maybe we ought to change some of this.
          Brian: The third party is not asserting that the origination is that
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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
          Jonathan Lennox: Will there be ops guidance on how soon you need to
          get your
          Sean: Yes, but we provide the mechanisms, and other groups will specify
          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
          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
          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
          - 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
          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/
          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
          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
          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
          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
          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
          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
          that into the SIP traffic if we had something like a SIP identity
          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

Generated from PyHt script /wg/stir/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -