Stir Status PagesSecure Telephone Identity Revisited (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2013-Aug-30 —Chairs:
IETF-103 stir minutes
Session 2018-11-05 1120-1220: Meeting 1 - Audio stream - stir chatroom
Minutes - Secure Telephone Identity Revisited (STIR) - IETF 103 MONDAY, 5 November 2018 at 1120 Chris Wendt (Comcast) talked about draft-ietf-stir-passport-shaken. The document is in IETF Last Call, and this discussion focused on resolving issues that were raised. The origid field carries an opaque value that identifies the service provider, not the call originator, so it does not leak personal information. Chris to add text to Privacy Considerations pointing to base PASSporT specification and explaining that the use of origid. Jon Peterson (Neustar) talked about draft-ietf-stir-passport-divert. A recent question came up about having a signature over R-URIs. This document was created to handle a change to the administrative domain. Note that there are two very different use cases. The first one is call forwarding. The second one is a call to 1-800-United that us redirected to a geographic phone number. In the second case, the end user knows that the recipient is representing 1-800-United. The core mechanism handles both use cases, and there is no need to change the mechanism to address the R-URI. In exceptional cases, the R-URI changes, but for the standard call forwarding scenarios, the use of div is straightforward. Further, if a div includes a R-URI that is radically different than the original To field, then it is easier for a verification service to determine that it is not a cut-and-paste attack. The document is ready for WG Last Call. Jon Peterson (Neustar) talked about draft-ietf-stir-oob. This document is already in WG Last Call, but the WG Chairs haven't made a consensus call yet. The WG is going to publish this framework, but not protocol that implements the framework. Chris Wendt (Comcast) talked about draft-ietf-stir-passport-rcd. The group discussed whether it would be better to include a jCard by reference or value. A reference would be a URL to fetch the jCard. A value would include the jCard in the PASSporT directly. Alternatively, the whole jCard could be carried a SIP request, but the PASSporT signature could cover it. In addition, a reference naturally supports many formats, not just jCard. If integrity of the referenced jCard is needed, the reference can include a hash of the expected jCard. Of course, a jCard itself can have URLs inside them, and the hash value does not provide integrity for the objects that they reference. There is concern that including a jCard by value will make the PASSporT too large. The next version of the document will support both value and reference, and then we will see what actually gets used.