* 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 —  
Chairs
 
 


IETF-104 stir minutes

Session 2019-03-29 0900-1030: Karlin 1/2 - Audio stream - stir chatroom

Minutes

minutes-104-stir-01 minute



          STIR WG, IETF 104
          FRIDAY, 29 March 2019 at 0900, Karlin 1/2
          
          Chairs: Russ Housley, Robert Sparks
          
          Minute Taker: Jean Mahoney
          Jabber scribe: Sean Turner
          
          Summary of actions:
          
          ACTION: Jon to create errata on RFC 8224: add DQUOTE to ABNF of "token".
          ACTION: Mary Barnes, Ben Campbell and Eric Burger will review
                  draft-ietf-stir-passport-divert for WGLC.
          ACTION: Chris Wendt, Mary Barnes, Sean Turner will review
          draft-ietf-stir-oob
                  for WGLC.
          ACTION: Chairs to ask for adoption of draft-peterson-stir-cert-delegation
          on
                  the mailing list.
          
          --------------------------------------------------
          Administrivia
          presenter: chairs
          slides:
          https://datatracker.ietf.org/meeting/104/materials/slides-104-stir-chair-slides-00
          
          Agenda Bash - no changes
          
          --------------------------------------------------
          draft-ietf-stir-passport-divert
          Presenter: Jon Peterson
          Slides:
          https://datatracker.ietf.org/meeting/104/materials/slides-104-stir-divert-and-out-of-band-00
          
          slide 1: Title
          
          slide 2: draft-ietf-stir-passport-divert-04
          
          slide 3: What’s New in -05?
          
          slide 4: An Aside: quoted PPTs
          
          slide 5: Issues
          
          Jon Peterson - It should have a second WGLC. Any comments?
          
          Subir Das - On the quoted PPTs and RFC 8224 - do we need to correct
          the other
          claims?
          
          Jon - We've been consistent with quoting. I think we just need to fix
          RFC 8224,
          everything else uses quotes, like rph.
          
          Subir - We used quotes.
          
          Russ Housley - Do we need to do a bis?
          
          Jon - No, just add an errata. It's a one line change.
          
          Robert Sparks - Any volunteers to review the draft?
          
          Jon - Mary will read it.
          
          Russ - we need one more reviewer.
          
          Ben Campbell volunteered.
          
          Chris Wendt - I have read it.
          
          Jon - It has been thoroughly read on the ATIS side. I haven't read
          it. I just
          write, and keep my eyes closed.
          
          Russ - Mary and Ben will read it for WGLC.
          
          (On jabber, Eric volunteered to read for WGLC as well.)
          
          ACTION: Jon to create errata on RFC 8224: add DQUOTE to ABNF of "token".
          Clarify that the info parameter value is not quoted.
          
          ACTION: Mary Barnes, Ben Campbell and Eric Burger will review
          draft-ietf-stir-passport-divert for WGLC.
          
          --------------------------------------------------
          draft-ietf-stir-passport-rcd
          Presenter: Chris Wendt
          Slides:
          https://datatracker.ietf.org/meeting/104/materials/slides-104-stir-rich-call-data-00
          
          slide 1: Title
          
          slide 2: Overview of update
          
          slide 3: Three standard key/values for 'rcd' claim
          
          slide 4: Example of 'rcd' PASSporT with 'nam'
          
          slide 5: Example of ‘rcd’ PASSporT with ‘jcd’
          
          slide 6: Example of ‘rcd’ PASSporT with ‘jcl’
          
          slide 7: Further work/discussion
          
          Chris Wendt - Given the BIMI discussion, we talked about adding logos. I
          don't
          know.
          
          Jon - Saying this recklessly - I think that logos here are slightly more
          addressable in this case than BIMI. Mostly impractical rather than
          impossible.
          
          Chris - I'd like feedback on phishing in general. Is cnam a phishing
          attack?
          Are phone numbers like look like other phone numbers a phishing attack?
          
          Jon - Caller ID shows James Bond. Which one is it. Caller name in
          general has
          this problem. We're already screwed. Not any more screwed.
          
          Mary Barnes - I think we need this. In the other forum people want to
          see this.
          There are a lot of examples showing this
          
          Eric Rescorla (ekr) - We have an preexisting infrastructure that can
          attach
          identifiers to these things. The problem with BIMI and logos - we
          are talking
          about a new infrastructure that we don't know how to manage - how
          to populate
          it?
          
          Chris - We need to think about those things.
          
          Jon - I'd put one up if you were to pay me money for it. Apple does this
          already. This is in the wild. Can we do better than what is in the wild?
          
          ekr - Would Apple arrange to show a Cisco logo when Cisco calls an Apple
          device. Does anyone else do this?
          
          Ben Campbell - Logos appear on spoofed calls from Apple.
          
          Richard Barnes - Yes we have an existing infrastructure of authorities,
          and we
          can propagate and authenticate it. It's only an issue with global
          interop, I
          don't think it's this case.
          
          Jon - The global email problem is intractable. The NA free phone numbers
          have a
          very particular authority structure. There's a responsible organization
          associated with every free phone number. There's a chain of authority for
          attesting who that is. I can imagine a registry created just for that. A
          narrow use case.
          
          ekr - If only Fortune 500 companies are allowed to have this - Sure.
          
          Richard - For emails, they don't have these pre-existing authorities,
          and they
          don't want to introduce them, don't have a proposal for it.
          
          ekr -  The BIMI case was for four email providers -- Microsoft, Yahoo,
          Google
          and AOL -- can have logos appear. The problem is that a logo for RTFM
          would not
          appear. The problem is not the authority structure, it's who has the
          authority
          for the logo.
          
          Russ, as individual - I'm worried that it is a URL to an logo image
          and there
          is no hash value in the signed object to make sure the website provider
          doesn't
          change the logo. An integrity mechanism is needed to ensure so that
          the signer
          of the PASSporT knows the logo that is going to be displayed.
          
          Jon - I'm not sure I understand the attack. The original service provider
          inserts the URL, has control over the website, signs the jcard. It's
          an https
          URL. If the case is just Fortune 500 companies, they can point to HTTPS
          websites that then can point to the logo. If it's originating service
          providers putting this in, I'm happy if it's optional.
          
          Russ - I am not - the Fortune 500 website has a CDN in front of it - the
          credential is not one-to-one as you are describing it.
          
          Jon - What is the impersonation threat model here?
          
          Russ - The point is, you want the signer to know what they are signing.
          
          Jon - the point in STIR is that there is a particular set of threats
          that we
          are trying to mitigate.
          
          Russ - You are now adding a logo that is not bound by the signer.
          
          Sean Turner as Jabber Scribe, for Eric Burger - Eric will review the
          previous
          draft. Or that the logo is some kind of tracker. Note, we don't need
          to worry
          much about the tracker, because we have cryptographic identity (and
          after we
          finish talking about the reference being kind of in the signature),
          we do know
          (and can decide about showing), per Jon.
          
          ekr - There are two cases. I sign up for the system, I'm an attested
          caller.
          For instance, I'm United Airlines. I have a logo and I call Jon, and
          then I
          change the logo to be Delta and sorry Mr. Peterson your flight is
          canceled, why
          don't you come to United. Is that the attack?
          
          Russ - I was thinking about the website being hacked, swapping what gets
          displayed, and you get the logo with extra Micky Mouse ears on --
          
          ekr - The attacker is not the attesting party. The attacker is attacking
          where
          the logo is hosted. I would be happier with it being treated as a link,
          not as
          an authority. Every time I get a phone call, now I have to hit the
          website - if
          this Akamai. Having a hash solves that problem. You can do hash
          caching. What
          resources are being conserved without the hash?
          
          Jon - The jcard is big. We can make the hash mandatory. Not a big deal.
          
          Chris - W3C has an integrity header.
          
          Jon - The defacing the logo, I can see that as an attack.
          
          Chris - Should it be a hash across the entire jcard - the URL and image?
          
          Jon - No
          
          ekr - You want the URL and the hash of the image together.
          
          Russ - Correct.
          
          ekr - The object consists of a URL to the image and a hash of the
          image. If the
          hash don't match, you have a problem. If I have an object with that
          image in
          cache, I just display it rather than looking it up.
          
          Chris - How to insert that? Maybe define the jcard thing. Would need
          to know
          what the hash is pointing to. Have to figure it out.
          
          Sean for Eric - At some point the URL + hash will be about the size of
          the jpg.
          
          Russ - No.
          
          Chris - I agree it would be shorter, we're talking about multiple identity
          headers anyway.
          
          Jon - Do we want to talk about JSON vs jscontact?
          
          Chris - There was a new effort for canonical JSON.
          
          Jon - There's an alternative plan for doing JSON in vCard, but their
          plan is
          not to adhere to jcard semantics, would look more like a JSON object.
          
          Chris - I don't think there are huge issues. the JSON was directly
          translated
          from XML and it is a little fuggly.
          
          Sean - It is. I like idea that it's ... and just converting it.
          
          Chris - I think we have it and it should work.
          
          Mary, as individual - I would rather us not do that. The Dispatch
          WG didn't
          agree on the way forward for that work.
          
          Chris - Just to address it in case people have questions. Can always
          define new
          key value pairs in the future.
          
          Mary - Not now.
          
          Sean for Eric: I don't think we need to wait another year for JSCARD,
          if it
          happens at all... BTW, 608 shows jCard is good enough.
          
          Sean - Whatever that is.
          
          Chris - sipcore-rejected. I think everyone is agreeing on that point.
          
          --------------------------------------------------
          draft-ietf-stir-oob
          Presenter: Jon Peterson
          Slides:
          https://datatracker.ietf.org/meeting/104/materials/slides-104-stir-divert-and-out-of-band-00
          
          slide 6: Title
          
          slide 7: Basic STIR Out of Band
          
          slide 8: What's new in -04
          
          slide 9: Next Steps
          
          Robert - It would benefit from 2nd WGLC and a couple of dedicated
          reviewers.
          This one's easy. Any volunteers?
          
          Chris, Mary, and Sean volunteered.
          
          ACTION: Chris Wendt, Mary Barnes, Sean Turner will review
          draft-ietf-stir-oob
          for WGLC.
          
          --------------------------------------------------
          STIR Certificate Delegation
          Presenter: Jon Peterson
          Slides:
          https://datatracker.ietf.org/meeting/104/materials/slides-104-stir-certificate-delegation-00
          
          slide 1: Title
          
          slide 2: draft-peterson-stir-cert-delegation-00
          
          slide 3: Delegation and Authority
          
          slide 4: How does STIR use it?
          
          Richard Barnes - +1, for that approach, a necessary and sufficient
          condition
          is that the relying parties are instructed to enforce the hierarchy.
          
          Jon - They are. That's why theres AS/VS behavior in here that talks
          about the
          expectations of the VS. There are some hard edges, like when delegating
          from
          an OCN to a TN block. This requires domain expert knowledge to determine
          the
          encompassment. I don't know how to fix it; I don't think it can be fixed.
          There are databases that say which TNs are under which OCN, and you need
          database access to decide whether a particular TN or block is encompassed
          by
          an OCN.
          
          Richard - Some certificate chains that have OCN-to-OCN hops will not
          be globally
          verifiable. Calling from CZ to Malaysia, and they try to verify against
          some
          Czech db. They won't be set up to do that. But that's kinda okay with me,
          because most use cases are in zones where people have this set up. Where
          it
          fails, creates pressure to create TN all the way certificates.
          
          Jon - This emerges from North American deployments; it has this property
          based
          on SHAKEN principles. I don't see how the general delegation should
          work for
          STIR; the assumptions always apply. Those entities that participate
          in IPNI
          within ATIS have access to that. People who are verifying it, have
          access to
          those resources. It's a trusted network in the RFC 3324 sense, the SHAKEN
          PASSporTs have to be stripped if they exit the trusted network.
          
          Mary - You can get this data from somebody. We have other problems to
          solve if
          we want this to work globally.
          
          Chris - we are slowly transforming the network. Hopefully the network will
          evolve.
          
          Sean - I echo all of that. There's this verification system that will
          do this.
          The worry that a CA will pop up and start doing stuff - pretty hard for
          that to
          happen in this system.
          
          Richard - This is not blocking. The document should be clear that this
          is a
          hard edge. Be nice to provide links to help people connect to these
          databases.
          
          Chris - That's the assumption we have in SHAKEN that it's an implicit
          association with OCN. That you should verify that the TN is owned by OCN.
          
          Jon - I think there's a caveat in the document. We design STIR here, not
          SHAKEN. STIR is high-level. SHAKEN will have to provide far more
          detail for
          North America.
          
          Sean - I see this as future proofing the document.
          
          Richard - There's general PKI issuance stuff to put in the security
          considerations. Make sure you prove possession of private keys. If you
          go out
          into the wild, here are some bears to watch for.
          
          Russ - There will be a Certificate Policy somewhere.
          
          slide 5: ACME (through a STIR lens)
          
          slide 6: Future Work
          
          Chris - Would partial delegation apply to RFC 8226?
          
          Jon - Yes, already mentioned in RFC 8226.
          
          Richard - 3 letters for you - EKU. This seems extensible.
          
          Jon - We don't want to reinvent X.509 here.
          
          Jon - Connected identity is STIR in the backwards direction -- know that
          you've connected to the right identity. The SIPBRANDY work plugs into this
          as well.
          
          Richard - RFC 8555 has fields that say I want this to be that short. The
          CA
          can apply policy. What other work is necessary?
          
          Jon - We had text in the short-lived certificates document that talked
          about
          tradeoffs with OCSP. We were trying to figure out if we should do OCSP
          stapling
          for validation. How to specify the ATC. Should the authority be able
          to say
          that your token expires in 5 seconds because you're a punk.
          
          Jon - Certificate conveyance with X5U with CID, but haven't fleshed
          it out.
          Should it be a header. There are chains now.
          
          Richard - JWT has a X5C slot where you can stick these things.
          
          Jon - Maybe we should to that - X5C. Change everything in RFC 8225.
          
          Chris - Certificate rotation mechanisms -- if we don't convey it
          directly, can
          we have a pointer to the new certificate before the current one expires?
          
          Jon - That's a generic capability.
          
          Sean - I want to echo that - CRLs suck. It's not working well. If it
          makes the
          industry consider doing better and faster, then I'm all for it.
          
          Mary - I don't want to figure out CRLs for this stuff. Can we add it to
          the new
          version?
          
          Jon - It's a short-lived certificates draft. Are you are volunteering
          to work
          on it?
          
          Mary - Yes, I don't like CRLs.
          
          Chris - This is very important stuff. People want to know how VoIP
          providers
          can start signing calls.
          
          Jon - Chris and I are getting hammered on this in the industry.
          
          Richard - +1, customers are asking for this.
          
          slide 7: Next Steps
          
          Robert - We can ask for call for adoption on list. If you do not think
          the WG
          should adopt this, hum now.
          
          Robert - If you do think we should adopt it, hum now.
          
          Robert - Room thinks it's the right thing to do. We do need to put it
          on the
          list.
          
          Sean for Eric - Think it should be adopted, way more important than OOB.
          
          ACTION: Chairs to ask for adoption of draft-peterson-stir-cert-delegation
          on
          the mailing list.
          
          --------------------------------------------------
          Wrap Up
          
          Adam Roach - There was a discussion around RUM, it may be useful to do
          work on
          Called party ID.
          
          Jon - That's connected identity. Definitely need it.
          
          Robert - Do the reviewers have vacations that would make starting
          WGLC next
          week difficult.
          
          EOM
          
          



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