IETF79 – Beijing ECRIT Meeting Notes summarized by R. Marshall Note: Matt Lepinski’s raw meeting minutes are appended. Meeting time: 15:20 - Tuesday, 11/09/2010 ---------------------------------------------------------------- Agenda as posted: 20 min * Agenda Bashing, Draft Status Update (Marc Linsner, Richard Barnes, Roger Marshall) 10 min. * Rough Location (Richard/Matt) http://datatracker.ietf.org/doc/draft-ietf-ecrit-rough-loc/ Intention: Discuss lastest changes - Ready for short WGLC 10 min * Additional Data related to an Emergency Call (Hannes) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Intention: Discuss if ready for WGLC 30 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (Hannes) http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Intention: Discuss latest changes and if ready for WGLC 30 min. * Public Safety Answering Point (PSAP) Callbacks (Hannes/Milan?) http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/ Intention: Discuss latest changes 30 min. * Trustworthy Location Information (Hannes) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Intention: Discuss latest changes 30 min. * Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices (Dirk) http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/ Intention: Discuss latest changes 10 min. * Open Discussion ---------------------------------------------------------------- /start --- Agenda Bashing, Draft Status Update (Marc Linsner, Richard Barnes, Roger Marshall) -- Note: Charter updated (see web), there will be yelling and screaming as the milestones get close -- Next ESW Budapest April 13-15 -- No other comments noted. /next --- Rough Location by Richard Barnes Authors have been negligent in updating draft to reflect reviewer, but it was noted that this has been remedied. Encouraged work group to read the document, promising that a new WGLC was soon to come. /next --- Additional Data related to an Emergency Call (Hannes) This mechanism is described as a way to get additional descriptive information to the PSAP, in the form of a "pointer" that is carried within the CALL-INFO SIP header. This additional data covers the "call", "the caller", and "(additional to) location". The work group discussed the sensitivity of the data, a proposal to deliver it using the v-card approach (a new version that uses xml). Since there were security issues discussed, there was a plea for a security focused review. The idea of having middle devices insert this pointer (on-behalf-of) was briefly discussed, along with potential security issues. Hannes would like to get reviewer input on the semantics of the actual elements. James Polk agreed to provide a review after the meeting. (No discussion of WGLC noted, since it was noted that it needed more review.) /next --- Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (Hannes) It was noted that CAP currently has limitations on location representation, in that only a circle and polygon for geo can be represented - no civic representation possible. There are two approaches to having location associated with a CAP message, 1.) is if the UA has location available, then it generates a PIDF-LO using the location information, and also separately attaches the CAP message, but ignores any location within. 2.) if the UA does not have location available to it, then it extracts the location within the CAP message and uses that to generate the PIDF-LO, which is doable. The reverse is not supported (i.e., putting location from a PIDF-LO into a CAP message). Sohel Khan requested an additional example use case of CAP use with sensors detecting a Tsunami warning. Authors of this draft, though wanting WGLC initially, agreed to a review by Sohel Khan. Cullen agreed. /next --- Public Safety Answering Point (PSAP) Callbacks (Hannes) Questions brought up by Richard on the applicability to PSAP identification - so that the user later receiving the call really knows that it's the PSAP that is calling. Hannes clarified that this document is only concerned with discussing how to give preferential (or, "different") treatment to calls from the PSAP that are callbacks. See minutes on details of discussion around PSAP IDs and certificate fingerprint and on questions from John Elwell regarding the viability of SIP Identity with B2BUAs. Jon Peterson raised the idea of a "PSAP token" handed over to the user by the PSAP, so as to verify the PSAP. Keith Drage brought up the point that it is very important that intermediaries along the call path can tell if an incoming call is one that is indeed labeled as a PSAP callback. Martin Thomson suggested that this could be done by deleting or adding a SIP header. Hannes advocated that we stick with the SIP Identity-based authorization, and leave it in the body. Hannes agreed to the idea that the alternative approaches be listed with trad-offs, so that the working group better understands. Jon discussed the potential weakness of a failed callback because of certificate expiry. Paul K. made the cautionary point that if something is a property of a call, but not the property of the address, then we don't want overload the address elements with non-address information. /next --- Trustworthy Location Information (Hannes) It was noted that the GeoPriv threats RFC is more privacy-focused, and ECRIT threats RFC is more call-marking focused - therefore neither is particularly applicable here. Authors seeking review - particularly with regard to suggested text around accountability issues. Martin Thomson wondered if the wg should punt and seek outside input. The chairs agreed to get in touch with the security area to initiate a dialog on the draft. Currently, the draft doesn't provide a solution, but just explores the issues, though Brian Rosen wants us to get to a developed solution. /next --- Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices (Dirk) Authors stated that many changes have been made to the document, and believe that the document's readability has been enhanced. Hannes requested of James to compare this document with the ECRIT-direct draft. A few editorial comments received from Bernard Aboba on section 6.2 & 6.3 (see minutes for details). Dirk requested comments to section 6 be sent to the list. A poll was taken as to serious member interest on the draft. About 5-ish hands were noted. Chair seeking additional discussion on the list. It was noted that this topic won't go away, so it will eventually need to be handled given requirements that exist in other groups. /next (and last) Open Discussion – nothing noted. ====Raw meeting minutes follow – per Matt Lepinski===== Here are the notes I took during the IETF 79 meeting of ECRIT. I attempted to capture as much of the discussion as possible, but I'm sure I missed a few things. Note that specific action items are flagged with the key-word IMPORTANT (in caps) ----------- ECRIT ----------- **** Chair Slides -- See slides for document status -- Note: Charter updated (see web), there will be yelling and screaming as the milestones get close -- Next ESW Budapest April 13-15 **** Rough Location by Richard Barnes -- Authors have been negligent in updating draft to reflect reviewer comments ... this has been remedied -- Please read the document, new WGLC coming soon **** Additional Data for Emergency Calls by Hannes Tschofenig -- Note: Slides by Brian Rosen, but presentation by Hannes -- Re-uses the work done in the NENA additional data working group -- High-Level Mechanism: Use a URI, carried in the SIP Call-Info header, pointing to an XML document -- This mechanism for sensitive information, therefore there are significant security questions related to both control access to additional data, and ensuring data authenticity (should it be signed? if so how and by whom?)     (Note: Eventually, this could even be used for medical information) -- Comments/Suggestion/Review related to security would be very welcome -- Martin T: Note that vCard is developing a parallel XML format, we should be able to re-use that              I suggested previously MIME/multi-part before I was aware of the XML schema for vCard              Idea: Use a high-level XML structure and then insert the XML schema for vCard whenever you need a contact information element -- Note: Do we need a mechanism that enables an end-device to instruct an intermediate device to attach information           If we have that use-case, what is the privacy story for such a mechanism -- Brian R: Talked to some of the vCard people, and he believes it is appropriate for our use -- Brian R: There is no use-case for a third-party to insert data (from a NENA point of view)              ALso, NENA already has a different mechanism for medical information -- James P: The service provider can insert anything about itself, but it should not go and fetch (potentially private) information about the user -- Brian R: The service provider can insert __ITs OWN__ information, but not information about the user -- Roger M: From the IETF point of view, where do the use-cases need to come from. Is this something that we expect NENA to provide all the use-cases we consider -- Richard B: The only things that have a protocol implication are: (1) Do we need an indication of who inserted a piece of data?; (2) Do we need a way for the UA to request that a particular piece of data be inserted?        ANSWER to this seems to be no requirement for either (1) or (2) -- Martin T: The identity of the insert-er will be in the XML -- Cullen J: Do we care that anyone on the path can delete this information?      Brian R: It's a concern but it's not something we need to explicitly deal with, this is not intended to be high-assurance data -- IMPORTANT ==> Hannes: Another thing I'd like to get feedback on (from reviewers) is about the semantics of the actual elements -- IMPORTANT ==> James Polk has volunteered to do a quick review on this draft after the meeting **** Data Only Emergency Alerts by Hannes -- Note: CAP has limitations on location representation     ... Only circle and polygon for geo and no civic at all -- Clarification: The end-point that adds location, has two choices, if it has location then it attaches that location (in the PIDF-LO) and attaches the CAP message     ... otherwise if it doesn't have location information, then it can extract the location info from the CAP and convert it into location in the PIDF-LO -- Martin T: The CAP message contains a proper subset of location that can be represented in a PIDF-LO     ... If we get a CAP message, we can always get that location into a PIDF-LO         (The reverse is not always true, but that's okay because the draft is never asking us to transfer location from a PIDF-LO into a CAP) -- Authors claim this is ready for working group last call     ... In particular the authors are looking for feedback on the text explaining the use of CAP -- Two hands for people who have read,understood, and liked this document -- IMPORTANT ==> Request by Sohel Khan for another example of sensors detecting a Tsunami     Chairs (and Cullen) have agreed to send an email reminder to Sohel Kahn to do a review     sohel_khan@cable.comcast.com **** PSAP Callbacks by Hannes -- Currently the draft is based on identity-based authorization (not trait-based authorization) -- Clarification (Richard): The requirement to identify PSAPs seems like a secondary requirement     Hannes: A goal of the draft is to only give preferential treatment to calls from the PSAP that are callbacks -- Richard: Does the draft go into how one maintains a list of valid PSAP IDs?     Hannes: No, that's going to be nation-specific (USA will have it's own way of doing this)     Richard: Could we use LoST to obtain a list of valid PSAP IDs? ... we could add a certificate fingerprint field into LoST -- John E: If you rely on SIP Identity then things won't work in deployment with back-to-back user agents     [err ... John had another comment but I missed it, hopefully the other note-taker got it] -- Keith D: Objection to the word "preferential" ... treatment will be different, but may or may not be "preferential" -- Jon P: Have you considered the device in the initial call provides a token to the PSAP, so that when the PSAP calls back, possession of this token indicates that the call-back is from the PSAP     Hannes: How would someone other than the UA do the verification of such a token?             (If it's someone on the forward call path, that person would see the token on call setup)             (If you have a pool of routing entities they may be able to synchronize knowledge of the token, maybe) -- Keith D: Important requirement for intermediaries along the path to be able to determine that an incoming call is a PSAP callback -- Martin T: Keith's concern can also be addressed by just using the presence or absence of a particular header (e.g. a token carrying header)               ... provided that you can trust the person who added the header (due to Identity or P-Asserted Identity) -- Hannes: If we stick with the model of Identity-based authorization, I think the body is the right place to put it -- Hannes: We could explain several alternatives so that people can better understand the trade-offs ... and then solicit feedback -- Jon P: I understand that there's a challenge here because you don't want (in an emergency) someone to reject a callback from a PSAP because SIP-Identity breaks on account of certificate expiration -- Pual K: If something is a property of a call, and not a property of the address, then we don't want it to put that something in the address **** Trustworthy Location by Hannes -- Note that GeoPriv threats RFC is more privacy-focused, and ECrit Threats RFC is more call-marking focused ... and therefore neither is particularly applicable here -- Authors seek review : particularly with regards to text suggestions on accountability issues -- Martin T: Perhaps we should punt for now, and seek out people to go into more depth in the future -- IMPORTANT ==> Chairs will get in touch with the security area to initiate a dialog on this draft -- Currently this document doesn't have a solution, it just explores the issues     Chairs: When we took on this work we understood that documenting the issues and the problem was important even if we didn't get to a solution     Brian R: Wants an actual solution **** Unauthenticated Access by Dirk --  Hannes: We have made many changes to this document, and the authors believe that they have significantly enhanced the document's readability --  Hannes: James please look at the relationship between this document and the ECRIT-direct document -- Bernard A: Section 6.2 = Don't use Emergency.com it's registered to a commercial entity                Section 6.3 = You can't use anonymous DH with EAP-TLS, RFC 5216 -- Dirk: Please put any comments on Section 6 to the list -- Chairs ask for show of hands and get 5-ish hands for people who are seriously interested in this topic -- Chairs request additional discussion on the list      Note: this topic won't go away, we really do need to do something in this space     (I.e., there are requirements in other organizations for unauthenticated access)