* 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-102 stir minutes

Session 2018-07-18 1520-1650: Van Horne - Audio stream - stir chatroom


minutes-102-stir-01 minutes

          IETF 102
          2018 July 18, Wednesday 15:20-16:50
          Van Horne
          Chairs: Russ Housley, Robert Sparks
          Minute taker - Jean Mahoney
          Jabber Scribe - Rich Salz
          draft-ietf-stir-passport-shaken received a Last Call comment about
          whether SHAKEN
          should have a compact form.  Chris will send a sketch of the text to
          add to the
          draft to the list.
          Sean Turner, Mary Barnes, Christer Holmberg and Eric Burger volunteered to
          review draft-ietf-stir-passport-divert (Eric handed a marked up printout
          to Jon
          during the meeting).  Whether nesting should be a MUST or SHOULD was
          The sense of those in the meeting was to go with MUST.  Further discussion
          sent to the list.
          draft-ietf-stir-oob is ready for WG Last Call.  Those in the meeting were
          comfortable publishing an architecture and outline of what a concrete
          might look like, but not publishing a concrete protocol at this time.
          The filed errata against the "iat" content in RFCs 8224 and 8225 were
          discussed, and those in the meeting agreed that the current use of
          the same
          timestamp as in the Date header addresses our threat model best, and
          that we
          want more operational experience before saying anything different.
          The errata
          against the "mky" content were also discussed, and Jon reminded the
          group that
          DTLS-SRTP was the mechanism chosen to secure RTP audio.  The discussion
          in the
          meeting noted that we would be better off not creating a generic
          mechanism for
          allowing other technologies (such as securing MSRP with TLS).  Instead, if
          including such technologies in PASSporTs is desired, separate documents
          exploring the specific security properties of covering them in the
          would need to be written.
          Those in the meeting supported continuing work on the callflow examples
          the interaction of divert and history-info.
          The proposal to protect P-Charge-Info in a PASSporT was discussed.
          There was
          insufficient interest from those in the meeting to take the proposal
          Robert Sparks - Status of WG documents in flight - normal and in progress,
          nothing is stuck.  Do we need to talk about SHAKEN?
          PASSporT SHAKEN Extension
          Mary Barnes
          Mary Barnes - No comments from WGLC.  Are the chairs ok with that?
          Jon Peterson - Why doesn't SHAKEN have a compact form? There are shadow
          P-headers in the 3GPP, there's no reason that it can't.
          Mary - I'm not in 100% agreement.  People are already starting to
          We can look at it later.  The P-headers should be brought here.
          I talked about
          it at the 3GPP meeting.
          Jon - It seems like an easy thing to add/specify.  Don't have to use it.
          Mary - Those P-headers aren't in our documents.  They exist in slides.
          the only documentation.  We can push for standardization.
          Russ Housley - There is nothing to reference at this point.
          Robert - Putting the capability into the document, even if we don't have
          anything to point to.
          Mary - We need to talk to Chris.
          Robert - If he shows up, we'll come back to it.  Otherwise we take to
          the list.
          Russ - Jon, would you please make your comment on the list?
          ACTION: Jon Peterson to ask on list about compact form for SHAKEN.
          PASSporT divert
          Jon Peterson
          Eric Burger - A 50Kbyte SIP message, or one with 50Kbyte long lines
          will be
          properly digested...  Can go either way.  If the driver is OOB, it is not
          compelling to me, though.  A SHOULD would not be implemented.  Pick one
          make it a MUST.
          Jon - The previous sense of the room was to leave it as an option.
          Didn't want
          to make a MUST.
          Eric - This will drive people to use History-Info.
          Jon - History-Info is service logic tracker.  Not in our threat model to
          preserve service logic.  Not why we are doing this.  This is extra credit.
          Mary - History-Info is generic.  Originally it was service logic.
          You will do
          more work capturing this information than doing History-Info.
          Jon - If you put some of that information into your index ...
          Mary - That's what I'm saying, makes those scenarios easier.
          Jon - I think there are ordinary use cases that won't need things you are
          describing, not going to see more than one layer of nesting in 99.9%
          of cases.
          Mary - There's enterprise cases.
          Jon - That's a profile that is specific to the way SHAKEN treats
          endpoints that
          I wouldn't build generically for STIR.
          Mary - Doing it generically is a better thing.
          Eric - When I said you can zip up the different things, it is not to
          compress it.
          The signatures won't compress unless we failed on our choices.  It is
          the concept
          - if you want to put a thing into this CPS and get back this thing, that's
          independent of this.
          Jon - We discussed whether we should do nesting only for the CPS case,
          but for
          99.9% of the redirect cases, nesting makes more sense.  If you are
          forking it,
          you need to make 5 different PASSporTs - the server side would work
          better to
          nest those.  It was the 302 thing that put us over the line on this.
          It is extra
          credit.  You use Diversion when a 302 came back.  And you can sign
          something that
          you got from the redirect server.  New invite go out with a new target
          that led
          to the complexity.  That we would need nesting for the in-band cases.
          Eric - Lead with that, and then BTW that OOB could happen.  Instead of,
          gotta do this for OOB".  And then I would offer MUST.
          Jon - There were people who wanted to do it with separate Identity
          headers.  We
          would like operational experience.  I rather not say you MUST NOT do
          this with
          individual identity headers.  I want to say you SHOULD do it this way.
          If it
          doesn't work in a particular deployment, I don't want them to be out of
          compliance with the STIR specification.
          Eric - Sounds like the Rich Shockey infinite employment program plan;
          it is
          Jon - In the RFCplusplus BoF we talked about what it means to be a Draft
          Standard and Proposed Standard.  I think this meets the bar for Proposed
          Eric - We will leave that to our chairs and ADs.
          slide 4: A nesting optimization
          Jon - Is this a good idea or a bad idea? Can remove it but would prefer
          to keep
          the text.
          Russ - Anyone object to it staying the document?
          Mary - I don't think it is a good idea because you are revealing too much
          information and you are including privacy headers as well.
          Jon - It is your server and you're redirecting, you are deciding, and then
          generating the PASSporT.  And the one who does the redirecting generates
          passport.  They get to chose whether it is ok to share.
          Mary - We just won't do it in SHAKEN.
          slide 5: Issues
          Russ - Who will review the draft?
          Sean, Mary, Christer, Eric volunteered.
          ACTION: Sean Turner, Mary Barnes, Christer Holmberg and Eric Burger
          to review
          draft-ietf-stir-passport-divert.  (Eric has already completed a redline
          Eric - I'll start the discussion about SHOULD/MUST on list.
          ACTION: Eric Burger to start discussion of whether nesting should a be
          a MUST
          or SHOULD. (Completed.)
          Jon - How about - it MAY be MUST? (laughter)
          Rich Shockey - Editorial - it is ATIS and the SIP Forum joint task force.
          ask about MUST vs SHOULD here for using nesting.
          Jon - For using nesting in inband? That would mean you are not allowed
          to have
          an identity header with a div in it unless it has a nested PASSporT in it.
          That is what MUST means.
          Russ - Let's take a hum.  Do you prefer the document to say:
           - MUST
           - SHOULD
           - Don't care
          Russ - Consensus - The hum was slightly louder for MUST.
          Jon - I'll have to write up something about the trade offs.
          STIR Out of Band
          Jon Peterson
          Jon - Anyone want to convince me to do a protocol in addition to the
          Robert - Is anyone working on an OOB implementation?
          Jon - Is it important to solve the case where it is not SIP end-to-end?
          Richard Shockey - Yes, do it at some future time when we find the
          one carrier
          on the planet that wants to do this.  Attitudes can change.  Take this
          to WG Last
          Robert - Do we need to specify a protocol right now?
          Eric - Do we run the risk that people will think that we have solved OOB?
          Robert - It is clear that it is an architecture document.
          Eric - If someone implements ts something that doesn’t follow this
          will the work group say we cannot work on it because it doesn’t
          follow this
          Jon - I don't believe because we published BGP when someone came
          along with
          ISIS it meant they couldn't have an RFC.
          Russ - No.  The IETF does voluntary standards.
          (Chris arrived, and the conversation here shifted back to the -shaken-
          Chris Wendt - I haven't received any comments during WG Last Call.
          Robert - There this late comment about compact form.
          Jon - Shadow P-headers exist in 3GPP.
          Mary - We build a PASSporT with these P-headers.  They don't leave
          the service
          providers' networks.
          Jon - So it is illegal for the P-headers to leave the network, but not
          for the
          passport to carry those P-headers out of the network.  That's madness!
          Chris - My thought it would be info, not P-header - that would be
          the easiest
          way to do it.
          Jon - If want to just add a parameter that had the same function.
          I'd rather
          that they are in public specifications.
          Chris - In the IPNNI task force, the plan is not to use those.  If there
          is a
          noncontroversial way to define compact form and add them as identity
          Jon - That's fine, doesn't matter to me.  This started in our
          about PASSporTs were getting too big and you want to cut them down,
          the obvious
          way is compact form in SHAKEN.  If you want to use P-headers or parameters
          that's fine.  I don't want to prevent that.
          Chris - You want them to be optional, so if you are doing full form you
          wouldn't need them.
          Mary - Correct.  I don't want that to be a dependency for this document
          to have
          that all specified.  You need to define the normative behavior for those.
          Chris - Purely there to support compact form.
          Mary - Correct, they are not in the proposal.  Proposal is to capture
          them as
          soon as they come into the service provider network.  If they leave
          the network,
          build the PASSporT then.  If they are not signing as it hops through their
          Chris - This is representing the origin id and the attest parameter,
          so if you
          are using compact form ...
          Mary - That's fine.
          Chris - I can add some text around that.
          Robert - Please send a note to the list outlining what you are planning
          to add.
          Chris - Yes, maybe I can also send the text.
          ACTION: Chris Wendt to send to the list an outline of compact form
          additions to
          Technical Errata for "iat" content and inclusion of "mky" (RFCs 8224
          and 8225)
          Tolga Asveren
          Jon - What's the risk of this?
          Tolga went over the use case on slide 3: "iat" Content/Call Flow
          Jon - We don't define what SBCs do.  This is not an ordinary PSTN
          I'm ok with that being the MAY case.  And what is in the documents
          should be
          the SHOULD case.  I'm unpersuaded.  This doesn't apply to the style of
          impersonation attacks we are are trying to defeat.  How do you exploit
          this? It
          encourages us to make our recommended date window larger, which makes
          it easier
          for hackers.  This is not how most calls occur.  I'm ok without SHOULD for
          most calls and a MAY for sometimes things.
          Tolga Asveren - The main reason to rely on Date was for the sake of
          form.  How much value is there saving on the time information itself? Is
          something tangible compared to the size of the message.
          Jon - That's the tradeoff.  If we want to save bits, but 99.9% of the time
          theres a small difference.  We assume clock drift, and it is unlikely
          to have an
          attack in the time.  It is because of that, we assume the difference is
          insignificant.  I asked around about JWTs and "iat" and looked at RFC
          7519, I
          don't think it mandates much.
          Chris - The philosophy of the correlating the date and the "iat" as
          our primary
          replay attack mechanism.  In IPNNI, we have been focusing on full form.
          did we want to represent the "iat" as it is meant to be? If you do
          have these
          application scenarios where INVITEs are held up in the network, then
          you have
          to deal with that in your application.  We should stick to the fundamental
          Tolga - What is the opinion of using the current time as the preferred
          form if
          full form is used rather than compact form?
          Jon - If the "iat" is different, you must use full form.
          Tolga - To turn it around - if you need to use the full form for some
          reason, would it be preferable to use current time over date?
          Jon - If it doesn't make a difference in the threat model, then we don't
          have a
          problem.  500ms makes no difference in how the validate service
          validates the
          PASSporT.  This was designed - the UE side signs it, the first SBC puts
          a new
          Date on it, but if you did full form, it should still work.  You want
          to allow
          this - SIP stuff gets munged in the middle of the network.
          Tolga - If you change the date, you should generate a new PASSporT.
          It is not
          given that an SBC would definitely change the date.
          Mary - I'm going to agree with Jon.  Let's get operational experience
          to see if
          we have a problem.
          slide 4: Inclusion of "mky" in PASSporT
          Jon - When you are doing TLS self-signed certificates in MSRP do you
          include a
          fingerprint in the SDP?
          Adam Roach/Ben Campbell - Yes.
          Jon - Yeah, ok.  I could see that.  How to errata that in RFC 8224?
          MRSP usage
          with self-signed certficates - a separate specification and to integrate
          in.  Is there burning interest?
          Tolga - I agree there is not a burning interest.  For your proposed
          wouldn't you run the risk that if you need to use it for something
          else, you
          would need to come up with a new document.
          Jon - Remember our threat model - beat an impersonation attack.  SRTP -
          impersonation deeply tied to telephone numbers.  I don't know if there's
          a lot
          of use cases.  Ben, what are you working on?
          Russ - S/MIME for messaging, but we are not using self-signed
          Ben - It is transport neutral.
          Jon - We put out one specification to update RFC 8224.  I don't want to
          do it
          speculatively - a=fingerprint.  Get some consensus that we want to do
          that in
          Tolga -
          Jon - We had the RTPSEC BoF about this - solutions for secure realtime
          The STIR threat model is about incoming telephone calls.  Hadriel was
          There was going to be something in the PASSporT.  Tie into a crypto
          instrument...  different device than the media was coming from.
          Tolga - Why the restriction?  What is the optimization?
          Jon - We had our Thunderdome.  We decided to do DTLS-SRTP.  When we
          built STIR,
          we wanted to create that binding between media layer and signaling layer,
          and a
          mandatory strength requirement.
          Ben - MSRP does require the use of the fingerprint attribute if one uses
          self-signed certificates.  Definition comes from the COMEDIA over
          TLS stuff.
          Robert - Jon's reminder of the conversation when we added the MUST.
          It was a
          well-considered, and widely participated group decision.  We put this
          to bed.
          The only shortcoming in the document is that we didn't write down
          enough why.
          Jon - It is not crazy to say how to do it with MSRP.  It doesn't beat our
          threat model.  Robo-calls are really annoying but not MSRP.  I wouldn't
          for a document that can do this for a some specific use case like MSRP.
          Robert - And the properties get vetted as opposed to creating a generic
          Jon - Exactly.  I don't want to say anything goes.
          Russ - To our AD - there are two errata that you have to process.
          Do you need
          anything more from the WG?
          Adam - Probably not.  If I need something later, I'll reach out.
          Robert - Then we will assume that you have all the info you need
          unless you
          indicate something later.
          Other Business (if time allows)
          SIP Call Flow Examples with PASSporT Diversion and History-Info
          Mary Barnes
          slide 1: Title
          slide 2: Background
          slide 3: Example
          Christer - I haven't read the text.  You are only signing the index.
          Mary - Correct.
          Christer - This doesn't sign the History-Info itself.
          Mary - It doesn't sign History-Info, you want to make the target the same.
          Christer - Is there text about that?
          Jon - All we are protecting are History-Infos to help you sequence it.
          Mary - Marianne Mohali will have to do this in 3GPP.
          Christer - I want to be clear - this is not a method for signing all of
          Mary - Right.
          slide 4: Discussion Points
          Jon - The gateway information isn't in the PASSporT?
          Mary - Yes, this is our SHAKEN PASSporT.
          slide 5: Discussion Points
          slide 6: Way Forward
          Mary - Should I continue with this?
          Jon - I support.
          Chris - I think it is a good idea.
          Christer - We should have examples.
          Mary - If someone wants to help, that would be nice.
          Christer - Should we include the Reason? You should define a compact
          form and
          put the value in the PASSporT.
          Mary - When we work through the work cases.  We'll see if it will work.
          Robert - When would this complete? I don't want this to be a frogboiling
          Mary - I was going to pick through History-Info call flows.  I can be more
          complete for the next meeting.  See if it is enough.
          PASSPorT Extension for P-Charge-Info Header
          Tolga Asveren
          slide 1: Title
          slide 2: P-Charge-Info
          Tolga - Used in SHAKEN context, and it pertains to billing.  Are people
          interested in my continuing this work?
          Chris - PASSporT is really based on origin/destination things.
          P-charge-info is
          on one side of a domain.  I understand signing it.  I don't have strong
          about it.
          Christer - Where is this is going to be used? It is used between trusted
          Procedure wise - I'm concerned about it.  It is an Informational draft.
          What if
          someone brings up Diversion header? Do we do Proposed Standard for
          the PASSporT
          Tolga - The notion of trust is not 100% black and white, there are
          shades of gray.  I understand the concern and point.  Trust is not
          an on/off
          Jon - How long have I waited to hear that!  RFC 3324 Spec(T)s and
          trust domains
          and how black and white they were.  If you are asking us for consensus on
          something that you couldn't get consensus on this.
          Sean Turner - PCI is an acronym in other contexts.
          Robert - My initial feel of the room is there is not a lot of enthusiasm
          taking it further.  And reasons to not to.  Tolga, do you understand?
          Tolga - Yes, if there is a change of opinion, they can express it on
          the list,
          but now there's not sufficient interest.  No need to progress this
          Wrap Up
          Robert - Do we need to meet in Bangkok? It feels to me that we are in
          a tail
          mode.  With exception of History-Info call flow drafts.
          Jon - We need to work on certificate stuff.  Not super pressing.
          It would organize
          acme work into how it plays here.  The connected identity stuff that
          Chris and
          I were working on.  I hear from people that they want this.
          Robert - We should request a meeting, it should be short.
          Jon - We are at the point now.  Let's look at what people do with this.
          the hump on this definitely.
          Robert - Any other other business?
          Robert - We are done.

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