* 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: Barry Leiba, Adam Roach, Alexey Melnikov | 2013-Aug-30 —  

IETF-105 stir minutes

Session 2019-07-22 1000-1200: Duluth - Audio stream - stir chatroom


minutes-105-stir-00 minutes

          STIR WG
          IETF 105, Montreal, CA
          Monday, 22-Jul-2019 10:00-12:00 Duluth
          Discussion of draft-ietf-stir-cert-delegation expanded to take the
          entire hour, and will continue on list. The chairs will schedule an
          virtual interim in September to follow-up and to make progress on
          Detailed Minutes:
          Chairs: Robert Sparks, Russ Housley
          Minute Taker - Jean Mahoney
          Jabber Scribe - Eric Burger
          slide 1: Title
          slide 2: Note Well
          slide 3: STIR WG Agenda
          Robert - anyone have an agenda bash?
          Brian Rosen - I would like to talk about emergency calling and what would
          be necessary to make a call back from the 911 system.  If the 911 system
          wants to, and they often don't, show a 3 digit number.
          Robert - if there's time.
          Martin Dolly - IP-NNI is working with ECIF to define requirements for
          when 911 is dialed getting to PSAP and getting a call back.
          STIR Certificate Delegation
          Jon Peterson
          slide 1: Title
          slide 2: draft-ietf-stir-cert-delegation-00
          slide 3: Why are we talking about this?
          slide 4: SPCs and TNs
          Mary Barnes - There are non-carriers that have OCNs.
          Jon - Yes.  The draft doesn't say, don't do that.  There are cases where
          you want to do that.  There are other cases, say, an enterprise that has
          had numbers for twenty years, nothing gets ported in or out, they're
          contiguous.  It might make sense for these entities to use TN blocks
          themselves in the certs.  One size doesn't fit all.  Sometimes OCN is
          overkill.  The hard edge is the concept of "encompassing", we stole this
          idea from RKPI.  This is an open issue in the draft - the terminating
          side needs to determine if the call should have been signed by the
          signer.  Need to understand where in the architecture to make the
          encompassing check.  Could do it when certs are issued or realtime during
          call processing at the VS.  Could impact call setup time.  Could do it in
          both places.
          Mary - We have a dependency on existing identifiers assigned to service
          providers.  Complicated because of number portability.  If you check on
          the verification side - have to check in more than one place.  You could
          do it on the authentication side - bind the CA token with the OCN and the
          Jon - This architecture would allow you to bind an OCN to OCN as a
          Mary - We have the notion of overall OCNs as well.
          Jon - Where do we want the authority and responsibility to reside in the
          architecture?  My preference is that it happens offline rather than
          during call processing.
          Mary - Whether or not we can make that decision here, we need to provide
          the tools.
          Jon - We do the plumbing here.  We can offer guidance on tradeoffs.
          Mary - I don't think we'll say you can only do it this way.
          Jon - I wouldn't leave the certification out.  The AS is also during call
          Mary - Can do it with the SPC token.
          Jon - You could.
          Chris Wendt - It should be possible to do lookup on LERG and NPAC and
          there's a mapping there.  Enable on both sides and let folks chose the
          front end or back end.
          Jon - Definitely.
          Chris - The key is that the end-to-end can be validated on both sides and
          you don't have to trust one side over the other.
          Jon - Verification services are going to access all kinds of analytics
          before alerting a user, any number of checks can be performed.
          Russ (WG Chair hat off) - The CA should check what it can before it
          issues the certificate; this is important for the reputation of the CA.
          There's an interval where certificate is valid, but things around it
          could change.  Allowing validation later is not a bad thing.  We need
          to accommodate those checks by people who can't do an NPAC lookup.
          Jon - That's the virtue of having the TNs be inscribed themselves for
          these enterprises in cases where it does work.  Having TNs in there helps
          the verification service that normally doesn't interface with the NPAC
          and the LERG.
          Richard Barnes - +1 to what Russ said - the CA should verify things -
          those are ground rules for PKI.  Need to make sure we're not engineering
          ourselves into a circle.  If these things can only be verified by doing a
          live check, the PKI is not adding value.  Given the sunk costs for PKI
          concepts, don't throw that way.
          Sean Turner - I don't know how you would write a CP that says in the
          validation section, "put whatever you want in there."  No relying party
          will buy into that.  You have to do pre-validation somewhere, otherwise
          what's the certificate good for?
          Jon - It puts a requirement on the CA to have access to those resources.
          Need to note in the architecture.
          Mary - As long as CAs are willing to buy into it.
          Jon - The CA and PA functions are modularized in SHAKEN.  We don't design
          SHAKEN here.  We aren't going to decide whether it is the CA's job or the
          PA's job.
          Mary - The databases are not real time.  Daily downloads are a newer
          Chris - The CA should be able to rely on the authority token.
          Jon - Agreed.  This is part of why we're not saying what we want to do in
          ACME because we're trying to figure this out.
          Richard - The "A" in "CA" is authority.  They exist to make statements
          upon which other parties rely.
          slide 5: To CA or not CA?
          Eric Burger for Wilhelm Wimmreuter - Do they want to delegate Endpoint or
          CA-Issuing certificates?
          Jon - We are talking about potentially delegating CA-issuing
          certificates.  Multiple chains of delegation - SPs that get numbers from
          a carrier that then provide those numbers to multiple customers.  I can
          imagine multiple levels of delegated certificates.  For typical
          operations, you as carrier would give your enterprise an EE certificate.
          Sean - If you decide to do TLS subcerts, you will get free security
          analysis to make sure you aren't blowing up TLS.  This idea might be
          better because there will be a formal proof to show the security works.
          Jon - My preference is classic X.509 delegation with the CA bit set.  If
          there is a market constraint against that, I would be willing to build a
          variant of subcerts just to get something out there, but that is not my
          Max Pala - What about proxy certificates that are X.509 certs with
          everything just restricted delegation.  They are meant to delegate to
          someone else without being CA.
          Jon - There is not a lot of them support the narrowing of the scope of
          the name.
          Mike - It's up to who is validating the certificates.
          Jon - We want the CA to tell you what you need to do to validate without
          having to do an external check.  If we hope to build that into the
          certificate, we need something that has a particular set of qualities.
          Think about RPKI encompassing, if you have a /16 and you want a subcert
          for a /24, does that work with proxy certificates?
          Russ - Yes, but not using the name constraints extension.
          Jon - We don't use classic X.509 name constraints.  We can look into it.
          Good suggestion.
          Cullen Jennings - Either of these paths solve the problem.  I lean
          slightly toward subcerts.  When I tell an operator or an SP that they
          will need to manage private keys for a certificate, they say, "Oh, no!"
          But if I tell them that they need to manage a token that enables you to
          do everything, they don't have problems with it.  One's easy, one's hard,
          but they're the same thing.
          Richard - I lean slightly the opposite.  The X.509 delegation is cleaner.
          There's more machinery, it just works.  The subcerts can be made to work,
          but it's greenfield, would have to add stuff to make it work with
          multiple levels of delegation.
          Jon - We would have to do another draft.
          Richard - There's running code though.  You won't get the
          interoperability that PKI has.  Between STIR-specific PKI and subcerts,
          might be a tie.
          Clint Wilson - I lean towards the subcerts.  We've working on
          implementing, it's more tenable from CA implementation perspective.  The
          X.509 delegation is a big no-no in web PKI, harder to make ... that
          supports that ability.
          Jon - I am sympathetic to that.
          Nick Sullivan - TLS subcerts is a key delegation, not a credential
          delegation.  It takes what's valid in the certificate and narrows the
          scope.  I don't see a problem with making a different variant.  This
          draft is for key lifetime narrowing.  I can see something completely
          different based on this work.
          slide 6: Smaller Questions
          Jon - Are we locked into x5u?  Is there too much code out there?
          Probably better to use x5c.  Chris, what do you think?
          Chris - I need more detail.
          Jon - The JWT can use either x5u or x5c.
          Chris - The chain is separate?
          Jon - It would be more syntactically accurate to use x5c to point to that
          Richard - It's just a value or reference question.  The x5c is a literal.
          On x5u, can you provide multiple certificates in the response?  I think
          it is the case.
          Jon - I thought it worked.
          Mary - I like the x5c.  We're discussing how to do the chaining in
          SHAKEN.  The x5c gives us desirable properties.  Chris is shaking his
          head.  We need to talk about it.
          Jon - We can say, let's allow either.
          Jon - Is there value in the "good bit"?  Some CAs can do the validation
          against these databases, others can't.  Maybe it would make sense to have
          a distinction between those CAs.  Those that can't do the validation
          would set the bit to no.  Maybe no one ever shouldn't?  I hear a vote for
          Chris - I was reading the JWT thing.
          Jon - Mary was saying she wanted x5c.
          Russ - I'm concerned that this has turned into an NPAC-centered
          discussion.  We need a solution that will work worldwide.
          Jon - Yes.  These tools will work worldwide.
          Chris - You can chain or certificate pointed to in both x5u or x5c.
          Jon - Let's keep x5u for now.
          Eric - As a validator, I can see that the good bit is good information
          that I can take into account.  But I can also see it as a restraint of
          trade.  Only special people get to be really good CAs.  We can discuss on
          the list whether people would use it, or is it just more lines of code to
          Jon - We don't want to create 2 classes of citizens, and suggest one of
          them is bad.
          Richard - If the good bit is false, and the encompassing semantics have
          not been verified.  What is the semantic that the certificate supposed to
          Jon - It conveys who the parent is, what their OCN is, what has been
          attested.  You might want to make sure it's correct.  I can imagine the
          case where you are doing a sub-delegation from a TN range to another TN
          range, you can look at it and know.  No need to look at an industry
          database.  It wouldn't require setting the good bit for you to be able to
          trust it on the verifying side.
          Richard - What would the semantic of the good bit being true be?
          Jon - The good bit is not relevant to that case, it doesn't need to be
          set.  The good bit would be relevant to its parent, from getting from an
          OCN to the initial TN range.
          Mary - You are correct.  It increases the confidence.  It can add to the
          analytics.  We are building up information of what we know.  This isn't
          as deterministic as you would like.
          Richard - Usually when an authority signs a certificate, it is saying it
          has verified it.  Here that statement is a one of a collection of facts.
          Jon - It is merely an input to broader analytics.  I would be content to
          dispense with the evil bit, I mean good bit, and just have the
          certificates.  If a CA is issuing them, it makes sure the encompassing
          semantics have been validated.  It is auditable offline.  There are not
          that many certificates.
          Chris - Being able to check 2-3-4 different ways is always good thing.
          Jon - We want to be able to verify in as many ways as we can.  We want
          this to work with as few shenanigans as possible during call setup time.
          slide 7: Next Steps
          Jon - Anyone think we're asking the wrong questions?  Anything else we
          should be doing?
          Martin Dolly - We talked about delegated certificates with our IPPBX lab
          in Middletown; will they do verification of IPPBX before they connect to
          our network?  They unanimously said hell no.  I shared this with IP-NNI,
          and I am sharing it here.
          Eric - Why?
          Martin - In the early 2000s, the IPPBX community was pulling IT functions
          into the enterprise, then later the pendulum swung, and the enterprises
          wanted the carrier to do more on their behalf.  Today, with cloud, it's
          moving further away from the enterprise.  Our vendors and customers are
          not going to be doing things like this.  In AT&T Flex ... servers our
          biggest servers, in our database, we have a list of numbers that our
          customers are using that are AT&T's, numbers that are customers are using
          that come from another carrier, we added a field for vanity numbers for
          Cullen - I'm confused.  I'm the CTO of the largest enterprise vendor of
          enterprise PBXes, and I know we want this, and we are implementing it,
          and we want to delegate it.  I believe what you are saying, but there is
          some miscommunication between the two of these.
          Jon - I have also talked to enterprises and carriers that want to
          delegate.  Some people may not want to delegate, and that's okay.
          Martin - Cisco was one of the vendors that I was speaking about.
          Cullen - Martin, I know you heard what you heard.  There are people
          moving more services to the cloud.  That's pushing a need for the
          delegation even more.  We could pull information from the vendors and
          find out what the actual need.
          Jon (going back to "Why are we talking about this" slide) - The
          motivation "push credentials from TN owners to an AS able to sign for the
          call" does not necessarily mean the enterprise will have these delegated
          certificates.  Maybe it's a cloud service or the outbound carrier.
          Martin, maybe your service will get the delegated credential from Verizon
          to sign for numbers that are for Verizon's customers, and you'll be the
          one using it.  My greatest fear is an outbound carrier that signs even
          though they don't own the number with credentials that have no
          relationship to the ownership that number, and we end up right where we
          started.  We have to get past it.
          Chris - The 2 use cases I see most are not PBX, but VOIP providers that
          do not have direct access to TNs and want a solution.  We have wholesale
          customers that support this work.  And the other, outbound call centers
          that want to sign the call and control what's being to shown to their
          Eric - I would offer that the last two statements [on the slide] are dead
          wrong; delegated certificates will make it better.  When AT&T gives
          attestation to Fidelity, that's enough for realtime blocking, for
          penalizing them if they're lying.  Making statements that AT&T is going
          to break --
          Jon - I didn't say that.  It's fine if AT&T does for Fidelity, but not so
          great if other carriers with different policies do it.  It's a
          goose/gander problem.  From a goose perspective, I don't want to have to
          do a lot, I just want to sign things.  The problem is the verification
          side once this gets to the gander.  This could tank this entire effort.
          Eric - Is this because of the focus of what is an attestation?
          Jon - The attestation levels are a factor, but I'm concerned that there
          is a class of carriers before STIR/SHAKEN came along who were willing to
          send illegitimate calling party numbers out into the telephone network,
          that are responsible for impersonation, voicemail hacking, and robo-
          calling.  If we say, "Hey it's okay for carriers to sign for whatever
          number they want" - with the best intention of having a set of reliable
          carriers, is that these irresponsible actors will leverage that to
          continue to impersonate.  Except now it will be signed with STIR/SHAKEN,
          and we've accomplished nothing.
          Eric - They will find themselves at the wrong end of an enforcement
          Jon - They will in trace-back terms.  It will take three months.
          Eric - It will be a lot faster.  That statement is not helpful.
          Jon - Real-time blocking and authorization have changed the story a bit.
          Attestation is orthogonal to this.  You need the information in real time
          if you're going to do real-time blocking.  Trace back has a different
          purpose.  I don't see the word attestation on here.
          Eric - Why do you say this doesn't enable real-time blocking?
          Jon - If the principle you're willing to accept is: "Okay, this was
          signed for by a carrier, someone who NECA is willing to give these
          Eric - And if that carrier is known to be delivering bad stuff and that
          number was signed by the carrier, it will get blocked.
          Jon - I said it was a good start.
          Eric - That's not a trace back thing, it's a whack the call thing.
          Jon - It's a real-time after trace back.
          Richard - Your assumption is that there some service who will tell me who
          the bad OCNs are, bad carriers.  Someone's has get on that list first,
          then they can be subject to real-time enforcement.
          Jon - And that is based on a pattern of bad behavior.
          Richard - There is validation of the control of the assets upfront.
          Someone cannot sign something they do not own.
          Jon - Even better.  Good start does not mean that it does not work.
          Ted Hardy - In other carriers, one of the issues is that it is relatively
          easy for somebody who wishes to behave as a gander to mint a new
          identity, and become a gander over and over again with new identities.
          This occurs in spam and impersonation, it occurs other places.
          Jon - This is question of how Newco works, and how you get OCNs.
          Ted - Is there a way for somebody who has previously been given an OCN,
          which has ended up on this list, to be traced to future applications to
          the same authority or not?  If the answer is no, then you are setting up
          a periodicity that's related --
          Jon - I get it.  It isn't quick, but there's are a lot of them out there.
          Some people may have opportunity to cycle through them rapidly, but it's
          a relatively constrained resource.  They're relatively difficult to get.
          There could be analytics that could let you make correlations, but it's
          Ted - In this case, since the OCN is relatively difficult to get, the
          threat model is whether the burden of creating a new OCN is met by the
          financial gain of being willing to be the originator of this sort of
          traffic.  We could figure out where that break point is.  That turns the
          question into whether the better situation where you never have to go
          through this 15 minutes already.  You never have to do this OCN lookup at
          all.  Is it worth the the additional effort and money that will go in to
          enabling these other use cases?  There's a risk here, which is not the
          same risk we see in environments where they're freely minting identities.
          It is not clear how that risk/reward will match once this is very common.
          Jon - There are more wrinkles.  Pseudo OCNs, like SPCs that are not quite
          OCNs, could have very different properties in terms of how they acquire
          them and how quickly they can be correlated.  There's a lot of edges that
          we'd need to analyze.  I was not trying to pick a fight with this, and I
          apologize if the way I put it was divisive.
          Mary - The overhead of getting another OCN won't be worth the effort.
          Jon - But if it's a pseudo OCN --
          Mary - They have to go through the rigamarole of setting up an account
          with the PA.
          Jon - Depends on how they are issued.  If it depends on the PA to issue
          Robert - We are out of time.  We will set up a virtual interim in early
          September.  I'll send out a poll.
          ACTION: Robert to send a poll for virtual interim meeting in September.
          Russ - Let's keep the discussion going on the list.
          [ End of meeting; ran out of time.
          [ Agenda topics for draft-ietf-stir-passport-rcd and updates on
          post-WGLC ]
          [ documents draft-ietf-stir-oob and draft-ietf-stir-passport-divert
          were  ]
          [ not covered.

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