[stir] Raw Notes for STIR@103

[Robert Sparks <[e-mail]>]

Many thanks to Jonathan Lennox and Jean Mahoney for taking notes during 
the STIR session at IETF 103.

Jonathan's notes can be found in the etherpad at 
https://etherpad.tools.ietf.org/p/notes-ietf-103-stir?useMonospaceFont=true

Jean's notes are copied below:

====================================================================

STIR WG Session

IETF 103 Bangkok
MONDAY, 5 November 2018 at 1120

Chairs: Russ Housley, Robert Sparks
AD: Adam Roach

------------------------------------------------------------
Administrative tasks
Presenter: Adam Roach
Presentation: 
https://datatracker.ietf.org/meeting/103/materials/slides-103-stir-chair-slides-00

(Slight delay in starting the meeting: Chair delays, Meetecho issues for
remote participants, stale Agenda cache that did not show session slides.)

Minute Taker: Jon (Lennox?), Jean Mahoney (backup)

Jabber Scribe: Christer Holmberg (who couldn't get into the Jabber room, 
Adam
Roach became backup scribe)

Bluesheets

Agenda Bash

Jon Peterson - Chris will present RCD, not me.

(no other changes to the agenda)

------------------------------------------------------------
draft-ietf-stir-passport-shaken
Presenter: Chris Wendt
Presentation: 
https://datatracker.ietf.org/meeting/103/materials/slides-103-stir-passport-shaken-00

slide 1: Title

slide 2: Some Comments to discuss

Chris - The origid identifier is opaque, and allows the service provider to
trace back where the call was originated, not the originator itself, no
personal info is being leaked.

Robert Sparks - For the Privacy Considerations, you should be able to 
point to
the base PASSporT spec, and it will talk about all these other things. But I
haven't verified that.

Jon Peterson - The Privacy Considerations in 3323 probably aren't well 
aligned
with this. This identifier doesn't contain any personally identifying info.
It's an opaque identifier of network resources rather than people. It's used
for service provider tracing. If you are concerned about people tracking 
this,
you can generate a new origid every time you generate a call. It's 
internal to
service provider networks. That closes the privacy gap, but point to 
PASSport
base spec also.

Chris - I'm happy to incorporate text like that.

ACTION: Chris to add text to Privacy Considerations pointing to base 
PASSporT
spec and explaining that new origids can be generated, and post to mailing
list.

slide 3: New Terminology text

slide 4: New Abstract text

slide 5: Other comments

Chris - I'll put a new version of the Privacy Considerations on list, and if
no comments, I'll release an -05.

Adam Roach, as AD - I will put this on the Telechat as soon as -05 comes out
unless anyone has an objection?

(no comments from room)

------------------------------------------------------------
draft-ietf-stir-passport-divert
Presenter: Jon Peterson
Presentation: 
https://datatracker.ietf.org/meeting/103/materials/slides-103-stir-divert-and-out-of-band-00

slide 1: Title

slide 2: draft-ietf-stir-passport-divert-04

slide 3: What's New in -04

slide 4: Pre-div in SHAKEN

Jon - a recent question came up about having a signature over R-URIs. I 
think
a R-URI is more ephemeral that is frequently modified. We might want to say
something about this though. What if you are an authentication service 
and you
get a call that you are supposed to sign, and the To and R-URI are already
different? Does the difference reflect a semantic change? A different admin
domain perhaps. How do handle it? We want to sign over To so the 
verification
service knows who the original caller was trying to reach. If we want to
change that, we'd have to change it in 8224. If you sign over R-URI and not
the To, it exposes a new class of attacks.

Jon - I kinda like things the way they are, and div was created to handle a
change to the admin domain that was semantically meaningful. Since 
people are
concerned about what to do - add language to div spec on why it works 
the way
it does. div is an array, we could sign both the To and the R-URI. Chris?

Chris - The freephone use case where the retargeting happens in the
originating network or intermediary network that was the most discussed. 
After
we discussed it, it's a different use case than typical call forwarding case
vs the case where you call 1-800-United and it's a geographic phone number
it's being redirected to and the end user knows it's representing
1-800-United. We need to talk about the differentiation between those two
cases in this draft, and accommodate those cases on the shaken side.

Jon - Redirection or retargeting cases on the originating side - that's what
diversion was created for. We have created plugins that make div work for
these use cases. I can imagine a auth service privy to a dip creating the
whole div. Whoever is generating those queries should generate the full div
for the call. I can add descriptive text to talk a bit more. The core
mechanism is correct. I don't see what we would change in the mechanism. We
should LC this and be done, right?

Robert - +1 on not trying to change the mechanism to address the R-URI. 
If you
consider the ATIS case and simplify it to a pure SIP case, and you receive a
R-URI that is wholly unrelated to the To, what does that mean for your
signature?

Jon - We don't constrain policy decisions of authentication services and
verification services. As long as you have the proper credential to sign the
To, I can see you doing it in that case.

Chris - We tried to make this generic and this adds some logic that makes it
complex. I guess that's SIP in general.

Jon - We could create a document on why authentication services and
verification services  should sign and validate things respectively. 
What they
should present to the application or user as a result of receiving a valid
passport. There's a bit of guidance in 8224, but it's policy free, we don't
say why you sign. If there was appetite in the WG to explore that more.

Chris - it's the exceptions that you can handle R-URI change, but for the
standard call forwarding scenarios, you should have a div.

Jon - That's my preference, if you are creating a div, if you have a R-URI
that is radically different than the original To. It makes it easier for a
verification service when it receives the request. So you can have some
assurance that it is not a cut and paste attack.

slide 5: Issues

Jon - I'm comfortable to go to LC with the spec as-is. Happy to have 
more eyes
on it.

Russ - Can anyone offer a reason why it is not ready for LC?

(silence)

ACTION: Start WGLC on draft-ietf-stir-passport-divert this week.


------------------------------------------------------------
draft-ietf-stir-oob
Presenter: Jon Peterson
Presentation: 
https://datatracker.ietf.org/meeting/103/materials/slides-103-stir-divert-and-out-of-band-00

slide 6: draft-ietf-stir-oob

slide 7: Basic STIR Out of Band

slide 8: Next Steps

Russ - WGLC has been initiated, but haven't had a consensus call yet.

Jon - We can have a consensus call that nobody cares and we can bring this
forward. The idea was worth documenting, but not worth driving into a fuller
mechanism at this point.

Russ - If I recall the agreement in Montreal correctly, we were going to
publish framework, but not details of protocol instances that 
implemented the
framework.

Jon - if anyone really wants to do this, I'll be waiting. I'll carry a 
torch.

Russ - We will make the consensus call - if there are any last minute 
issues,
post them immediately.

ACTION: If anyone has last-minute issues with draft-ietf-stir-oob, post them
to the mailing list immediately.

------------------------------------------------------------
draft-ietf-stir-passport-rcd
Presenter: Chris Wendt
Presentation: 
https://datatracker.ietf.org/meeting/103/materials/slides-103-stir-rich-call-data-00

slide 1: Title

slide 2: Overview of update

Chris - Any questions or comments?

Jon - The only thing I'd add - for some of the 3rd party cases we discussed,
there is a use in defining a ppt type for rcd because it would operate with
different passport rules.

Chris - Right, we didn't remove that, this is just an additional mechanism
that we added to the document.

slide 3: Example of 'shaken' + 'rcd' claim

slide 4: Additional Update to Discuss

Jon - I think we need it. There are a couple of ways to approach this. Do we
want to include a jCard by reference or value? Do we want a URL in 
there? You
could sign that compact form style. You could put the whole jCard in a SIP
request and sign over that in passport. If you use the URL approach that 
could
be in a separate SIP header, could sign that in compact form style. Doing it
by reference, you could have other formats besides jCard. Gives you
modularity.

Russ - We have experience with a certificate that contains a URL, it's a
longer lived thing than a passport. When it is done, you will see a URL
followed by a hash. If you chase the value from the URIL you compare it 
to the
hash. The signer and validator are both using the same dereferenced value.

Jon - when a SIP call is in flight you can imagine the jCard changing, that
could be surprising to the generator of the passport.

Ted Hardy - I'm a little confused about what security property would be
important when we are talking about a URI to a logo. There is content
negotiation possible based on where you dereference it. What your UA is
capable of displaying. The hashes to the canonical version have to be each
included. You get a lot of failure modes. The value of RCD is not 
exactly the
same as the certificate. I'm hesitant to do that unless you are sure the
elements for which you want to do a URL and a hash - the nature of 
object that
you dereference would be sufficiently static and last as the passport did.

Russ - Jon said that there are other places in SIP where we do this. My 
point
was, if we wanted to build a more general mechanism, then for some of them,
the signer and validator need to make sure they got the same object.

Ted - I agree, but where's that line? Would that go into this document or a
more general one that addresses the use of URLs in SIP?

Russ - Right now, the document has pass the whole value, there's no issue.
Only if we choose to support some things passed by reference. If it's only
RCD, I don't think there's an issue, if we go beyond that, need to make sure
the template isn't applied inappropriately.

Ted - That makes sense to me. You should limit the kinds of url schemes
permitted here the way SIP does. A mismatch seems problematic.

Chris - A jCard itself can have URLs inside them.

Ted - That's different, you will sign the jCard as an assemblage. You aren't
guaranteeing the objects dereferenced, you are saying this is what was
presented as the jCard. The results of that versus the results of trying to
sign dereferenced value are pretty different.

Jon - I'm just want to get compact form back. I'm worried about the size of
these things. If's a shaken passport, and we add a rcd to, and there's a 
div.
Anything we can do to cut the passports down. We can do by value or by
reference. By reference may have rough corners with e tags or hashes, that's
just a versioning system for content on the other side of it. I'd like 
to get
compact to work with this.

Chris - I like including that. To early to know what the industry would do.
Could see a future where all jCards are dereferenced through URL.

slide 5: Rich Call Data

Russ - Any last questions?

(silence from room)



------------------------------------------------------------
Any Other Business (if time allows) and Wrap Up
Presenters: Chairs

Russ - We have wrapped up with 7 minutes to spare. Thank you.