Minutes IETF102: stir
minutes-102-stir-01

STIR
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

Summary:

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 discussed.
The sense of those in the meeting was to go with MUST.  Further discussion was
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 protocol
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 PASSporT
would need to be written.

Those in the meeting supported continuing work on the callflow examples showing
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 further.

=========================Notes====================================

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
draft-ietf-stir-passport-shaken

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 implement.
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.  That's
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
draft-ietf-stir-passport-divert
https://datatracker.ietf.org/meeting/102/materials/slides-102-stir-divert-out-of-band-00

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 and
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, "we
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
experimental.

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
Standard.

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 the
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 review)

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.  Just
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
draft-ietf-stir-oob
https://datatracker.ietf.org/meeting/102/materials/slides-102-stir-divert-out-of-band-00

Jon - Anyone want to convince me to do a protocol in addition to the framework?

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
Call.

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 document,
will the work group say we cannot work on it because it doesn’t follow this
document?

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-
document)

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 header
parameters.

Jon - That's fine, doesn't matter to me.  This started in our conversations
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
network.

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
draft-ietf-stir-passport-shaken.

-----------------------------------------------------------------
Technical Errata for "iat" content and inclusion of "mky" (RFCs 8224 and 8225)
Tolga Asveren
https://datatracker.ietf.org/meeting/102/materials/slides-102-stir-errata-00

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 situation.
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 compact
form.  How much value is there saving on the time information itself? Is it
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.  What
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
philosophy.

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 other
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 that
in.  Is there burning interest?

Tolga - I agree there is not a burning interest.  For your proposed approach,
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 certificates. 

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
STIR.

Tolga -

Jon - We had the RTPSEC BoF about this - solutions for secure realtime media.
The STIR threat model is about incoming telephone calls.  Hadriel was here.
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 object
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 thing.

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
draft-barnes-stir-passport-div-hi-callflows-00

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
History-Info.

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 exercise.

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
draft-asveren-stir-p-charge-info-00

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 feelings
about it.

Christer - Where is this is going to be used? It is used between trusted nodes.
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
draft?

Tolga - The notion of trust is not 100% black and white, there are different
shades of gray.  I understand the concern and point.  Trust is not an on/off
thing.

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 for
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 further.

-----------------------------------------------------------------
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.  Over
the hump on this definitely.

Robert - Any other other business?

Robert - We are done.