ATOCA minutes from IETF-80 =Administrivia Covered working group status. ACTION: Chairs and AD to look into tools state of draft-ietf-atoca-cap. Secretariat have since updated this. =Requirements Discussion Part 1 - General Architecture Discussed scale of the architecture. - agreed that Internet scale is a goal, though smaller scale uses are important ACTION: Requirements document should include discussion on the full range of use cases. Agreed to include discussion on both ends (e.g., school closures, tsunami warnings) Discussed subscription model and what sort of behavior is necessary from recipients. - some form of explicit action might be necessary regardless of scale requirements Discussed filtering. - filtering on message content - filtering based on source (and not just identity, but attribute-based) - filtering at relays - taxonomies of alert types =Requirements Discussion Part 2 - Security Discussed the general problems inherent in pub-sub architectures (based on RFC 3265 and XEP 60) - access control, DoS, replays and MITM Discussed available mechanisms - noted that many are unsuitable either because they don't exist (SIP identity), or don't work (P-Asserted-Identity) Described trust model - who is trusted - originator/relay - how trust anchors are created - device provisioning, some form of discovery mechanism - differences in models with and without prior subscription ==Raw notes Thanks to Keith Drage and James Polk ===Keith (Note: s/Jeff Thom[p]son/Geoff Thompson/;s/Martin Thom[p]son/Martin Thomson) ATOCA ======= Agenda --------- Slides atoca-0 Administrivia - Chairs 5 min Status Active drafts draft-ietf-atoca-requirements draft-ietf-atoca-cap is not a WG draft Chairs said there was apparently no way of sorting this out. Keith Drage asked that this issue was sorted out, i.e. have the authors resubmit as an author draft (which apparently they have) and declare the draft with this name dead. Robert said there were issues with this (as of 3 months ago), but would investigate whether the situation had changed with the submission of the author draft. Requirements Discussion 40 min ----------------------------- Slides atoca-1 Brian Rosen Discussion to cover: scale; implicit and explicit subscriptions; alert filtering [Slide] Two ways to get alerts Broadcast Subscription [Slide] Scale is, of course, the issue We have some tools for broadcast (e.g. multicast), but not widely useful because not widely supported We would want to take advantage of it when we can We do manage to scale web queries, no reason to doubt we can scale broadcast The requirement is Internet scale James Polk: Concerned about making sure do not get an alert that it should not do so. Also authorised person fraudulently sending message. Presenter diverted to security discussion on second half of the agenda. [Slide] Connecting to alert sources Even multicast requires initial action on the receiver While some L2 specific mechanisms may be able to send alerts without any receiver action, can we assume a requirement that the receiver takes some action to connect to the alert source? Jeff Thompson: In our assumed configuration there is always some initial action (that will take some action to connect) Martin Thompson: Too easy to come up with requirements that are far too abstract. Wants to have things stated about what this should look like in practice. [Presenter then discovered he had the wrong slides] Ken Colvert: Not just talking about IP multicast, there is always application layer multicast. Subscription can also be dynamic. [Slide] Figure Hannes: ...did not catch... Presenter: Tree of subscriptions possible. Richard Barnes: Can have fanout of alerts. Either network later fanout or application layer fanout. Jeff Thomson: What is the difference between this as a newsfeed. Presenter: One solution would be RSS. Presenter: Some things in out system that are not in the RSS. [Slide] Not wanting to get too far ahead of ourselves If the receiver takes action to connect to the alert source, is this the same as subscription? We do clearly want to differentiate between "send alerts that affect me" and "send alerts that affect somewhere else". That might only be what location the alert is for ("mine" or "this") Janet (via Jabber): Elabourate because remote. [Slide] Filtering Not all alerts are of interest Location as a qualifier is a given What other filters might be needed? Source Classification Some kind of taxonomy Severity What else? Martin Thomson: Is the filtering based purely on the information in the alert, or whether filtering based on instructions from downstream point. Need to discuss this as a requirement, becuase if so, the downstream nodes need to supply information upstream. Presenter: This is dependent on doing things at the relay, which is valid. Martin: What info is included in alert to allow filtering. What info is fed upstream to allow filtering at a higher level entity. Presenter: Need requirement to filter on anything in the message. Scott: May not just be the identify of the source, but may need to be the characteristic of the source. What kind of source is it, e.g. local blogger or police. Jeff: Is this not just the information one has to put in ones subscriptions. Presenter: SIP SUBSCRIBE already has the notion of filters. Randall Gellens: Use a compound term for each class of filters. Hannes: What from this discussion should go into the document? Presenter: Document currently does a fair job of naming actors and flows. Some of the discussion on filters and taking action on ... needs to be in the document. James: Have we thought about a use case document by itself? Presenter: No. We can add use cases to the requirements document. Does not think a separate document is all that useful. Jeff: Need examples at both ends of the spectrum. ???: Can you filter based on the language? Presenter: That could be a filter criteria. Martin Thompson: Thought experiments. Please have this captured. Keith: If talking language also need to talk alphabet. Requirements Discussion (Security) 40 min -------------------------------------------------- Slides atoca-2 Hannes Tschofenig Discussion to cover: authentication and authorization [Slide] Two Phases [Slide] Subscription RFC 3265 talks about: Access Control Denial-of-Service attacks (of server's and third parties) Replay Attacks Man-in-the middle attacks Event packages may describe additional considerations. XEP 60 covers similar aspects. James Polk: Identified that there is a bis version of RFC 3265. Presenter: Depends on whether there are changes to the security section. Adam Roach: There have been no changes. [Slide] Message Delivery [Slide] KSTO1055887203 KSTO@NWS.NOAA.GOV 2003-06-17T14:57:00-07:00 Actual Alert Public Met SEVERE THUNDERSTORM Severe Likely NATIONAL WEATHER SERVICE SACRAMENTO SEVERE THUNDERSTORM WARNING SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY... TAKE COVER IN A SUBSTANTIAL SHELTER UNTIL THE STORM PASSES BARUFFALDI/JUSKIE EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA, EXTREME NORTHEASTERN CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN ALPINE COUNTY IN CALIFORNIA 38.47,-120.14 38.34,-119.95 38.52,-119.74 38.62,-119.89 38.47,-120.14 [Slide] MESSAGE sip:aggregator@domain.com SIP/2.0 Via: SIP/2.0/TCP relay.domain.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:dean@school.example.edu;tag=49583 To: sip:tony@foobar.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: common-alerting-protocol+xml Content-Length: ... ...... [Slide] Message Delivery: Communication Security SIP/XMPP End-to-End Security Mechanisms Authentication of originator Integrity protection Confidentiality protection Example mechanisms: S/MIME SIP Identity, PAI [Slide] Message Delivery: Alert Security CAP security Authentication and integrity protection Uses XML Digital Signatures Martin Thomson: How serious are we about XML digital signatures? Presenter: Requirements document does not go into this level of detail Richard: Keep the solutions stuff out of the requirements document. Cullen: Avoid SOAP size holes that you will never get out of. Also Javascript something? going on. [Slide] Example SIP MESSAGE method based on TLS and P-Asserted-Identify. Richard: Is there a contradiction here. Use of asserted identity implies no cryptographic infrastructure but the use of S/MIME implies that you have. Presenter: This example does not assume any digital signatures or suchlike. [Slide] Authorization Alert delivery: Where do the root certs come from? Once digital signature is verified what check is supposed to be performed to the author's identity? More likely that underlying SIP/XMPP communication architecture will be utilized!? Fewer problems where prior subscription step is performed. E.g. School case Originator's identity is asserted via SIP mechanisms. How to deal with messages from unknown authors/originators that appear out of the blue? Cullen: Things you are under serious delusions about P-Access-Identity. Will not be used to bill for 5c phone calls. Sceptical for treating SIPs identity mechanism as useful. One does not work and one does not exist. Richard: Some constraints to the problem that one can leverage. Sidestepping authorisation. How do I know he is someone that is supposed to send alerts. Today it is people who my local carrier authorise to send alerts. Can bootstrap up to find who your local server is and then make some authorisation to get into this space of authorised originators. Presenter: How would this local trust server get me get notifications about my daughter in Finland. Richard: Two things, getting to an alert server and veryfying that that alert server is authorised to send alerts. Cullen Jennings: Problem is different from the SIP identity problem in a number of ways. Here is a few parties going to send alerts to a lot of people. If write down english language policy of who is allowed to do what, crypographically it identifies what occurs. Can decide on asymmetric keying or symmetric keying based on that. Presenter: Subscription model. Cullen: Subscription model is a data transfer model. Brian Rosen: Seems easy to get an appropriate credential for kindergarten class, and similarly for the Tsumani warning. Scale problem is a lot bigger than that. Have to discuss what the transitive trust issues are. Martin: 3 sorts of things. Identifying the people you trust to provide. Relays taking alerts, what authorisation do these require before passing on alerts. Discovering identify in some fashion. Chair: How do you trust the relay agent and how does the relay agent trust the senders. The ultimate end may have less capabilities than the senders or relays. Brian: Relay agent cares less about the problem than the recipient. Richard Barnes: Disagree with Brian and agree with Scott. Jeff Thomson. Relay agents have a large vested interest in this. Richard Barnes will review the security requirements. Keith Drage identified that 3GPP SA3 had just started a work item of Public Warning System security. Work item only just agreed so no material to look at yet. They have a meeting in April that will carry this further. This should be investigated for relevance. Meeting ends 16:30. ===James Polk (Handwritten, transcription errors my own) ATOCA 3/31@1520-1720 by James Polk - Keith had a process issue about wg states of ID(s) - Robert will look into it. Brian's Reqs ID - Agreed to add use-cases to the reqs ID - to include a good breadth (e.g., Kindergarten's cancelled, Tsunami alert) Hannes' ID - Cullen has issues w/ PAI