CoRE WG @ IETF87 (Berlin) Minutes draft version 0.2. Chairs: Andrew Mcgregor Carsten Bormann Thanks to the notetakers (Etherpad doesn't seem to preserve the information who did that, unfortunately)! From these notes, compiled by Carsten Bormann. [Times/numbers in brackets indicate approximate position in the audio recordings and slide number.] MONDAY, July 29, 2013 1300-1500 Afternoon Session I Potsdam 3 APP *** core Constrained RESTful Environments WG ** Intro, Status etc. (10 min) Note-Well, Blue Sheets, Scribes, etc. WG Status: - in RFC editor processing: draft-ietf-core-coap-18 - old and new Milestones Carsten - Some milestones are missing from the chart, and also there are some new WG documents that are not listed. Carsten - Now that base CoAP is out there, we should be a bit wary about changing it and should more concentrate on deployment problems to solve. Carsten - Goes over packed schedule of this week including many planned hallway discussions. Carsten: between the core slots during this week, CoAP/LWIG prep (coordinated by Matthias Kovatsch) and observe prep (coordinated by Klaus Hartke) ** DICE BOF announcement/preview (10 min) (Zach Shelby) Objective: - briefly motivate the BOF - explain how this relates to, and differs from, the CoRE security work Zach - DTLS was a good choice for CoAP but DTLS has some drawbacks for constrained networks (including for multicast scenarios). Zach - Encourages people to come to the Wednesday DICE BoF. ** Access Control/Authorization in CoAP (50 min) Objectives: - sort through the drafts - obtain a general direction in which the WG wants to go with respect to any further standardization - relate to TLS, DICE and other activities Carsten - Stressed that CoAP doesn't do AAA (all that is done is delegate authorization to DTLS). In this way, CoAP is very unlike HTTP which does some AAA at the HTTP layer. Carsten - Some IETF activities already like OAUTH and JOSE that defines access control tickets. We will at some point have to understand what they are doing and see if there is any overlap. - Corinna Schmitt: CoAP/DTLS basics (5 min) (No presentation.) - Göran Selander: Access Control Framework (15 min) Göran - CoAP DTLS is good but simple in that it is an all or nothing Access Control. For example we may want different access rights for GET vs PUT. Or access rights based on local conditions (e.g. time of day). Salvatore - Are you talking of granularity at method level or on a resource level? Göran - It can be done at a URI (resource) level. Göran - Use OAUTH approach (in some cases a copy and past of OAUTH). Leif Johansson - Is this done before signing or are you reinventing JWS [JOSE]? Göran - This is just using JWS Göran - Couldn't get DTLS to work on our devices, so we also have an object security based approach Carsten - Comment: There is some room for interpreation for what draft-ietf-core-coap says on ACLs (not tied to the "root-access" approach -- the "all" in "all-or-nothing"). Anyone is free to come up with any ACL model. The question is: Is there some commonality that we can find? Leif Johansson - Relationship to OAUTH? Sounds like a holder-key-like mechanism. Maybe it would be good to back to OAUTH WG and ask for another transport binding instead of coming to CoAP WG. Göran - I am not an expert on OAUTH. We are using OAUTH approach of requesting an assertion (which is also used in other protocols). Leif Johansson - things that look like OAuth are but not exactly the same will confuse implementors in the future. Copying core assumptions from OAuth makes things tricky here. Göran - different types of assertions are allowed, not tied to OAuth-style assertions Göran - I would also like to ask the previous presenters (Carsten, Zach) to also consider an Object based security approach. Zach - Requirements/use-cases? Why do we need assertions? "Solution looking for a problem." Consider that this requires a lot of external communication (to get tokens, etc.)Where is the Authentication Server (devices may not be able to contact it at all). No decision yet made to abandon object security but DTLS session may be more efficient; payload overhead often is more important that anything else. And you need to look at JOSE as this is the proper place for object security. Göran - If we settle for provisioned ACLs, you need to reprovision new ACLs to all devices when changing the access rights, and then you need a method for authorizing the reprovisioning of ACLs. Instead of inventing a new method of this kind, we propose to use established authorization schemes. You don't need this if you're happy with static access rights. Zach - Object based security not excluded, but not on topic for CoRE WG Zach - Communication overhead is important Zach - Look at JOSE WG - Stefanie Gerdes: DCAF (10 min) (See slides) - discussion Olaf - Not exactly the same architecture as ACF where both client and server talk to the same third party Zach - Extensible to public key systems? Stefanie - Yes, but that's not the idea we're focused on Olaf - You can convey certificates, but you probably don't want to do that; not tied to shared secrets Zach - May want to ask: what is my ACL list? Relocation, ... few other things that need to be solved Stefanie - [___] Sye Loong - Interesting. Policy interpreter on the devices? Stefanie - Protocol does not specify how you structure your authorization information Olaf - Granularity: we used resource URIs and methods, or roles defined by AS(RS)/RS Sye Loong - Policy is passed from big brother to constrained device? ? - ? Barry - Who has read this draft and the previous one? (Very few hands) Barry - Please read the drafts before the meeting! Carsten - How many people in the room would provide comments on these drafts? 10-15 hands * other WG drafts: ** Groupcomm (Presenter: Akbar Rahman) draft-ietf-core-groupcom-11 (15 min) (Background reading: draft-dijk-core-groupcomm-misc-04 (0 min)) Objective of presentation: · Summarize updates since last IETF (i.e. Rev. 05 – Rev. 11) which have closed all known issues with the I-D · Request start of WGLC (if there are no more comments from the WG) Akbar - Are we fine with this? (Slide "Configuring Group Membership in Endpoints (2/2)") Zach - I like this. Would implementers prefer CBOR to JSON? Zach - Earlier comment on group membership discovery/pinging Olaf - CBOR easier to parse than JSON Carsten - Long time working on this draft. Reaching stable document? Need reviews. Who would do a review? 8-10 hands Carsten - Will do one review before the document goes to WGLC. (The other review was already done by Zach) ** HTTP-CoAP Mapping (Presenter: Akbar Rahman on behalf of Salvatore Loreto) draft-ietf-core-http-mapping-01 (15 min) (Background reading: draft-castellani-core-advanced-http-mapping-02 (0 min)) Objective: · Review requirements for HTTP-CoAP URI Mapping proposals · Review current proposals for HTTP-CoAP URI mapping Carsten - Who has read this? 2 hands Carsten - There are many proposed solutions. Disqualify those with obvious disadvantages and take it to the list. Carsten - The elimination of solutions can also be done via the WG list. ** Discovery draft-shelby-core-resource-directory-05 (10 min) Objective: - Discuss next steps Carsten - Who has implemented this? 5 hands Pete Resnick - Lack of comments is concerning. This is not good use of face-to-face time. Keith - Suggestion: Homework between the two sessions. ** Interfaces draft-ietf-core-interfaces-00 (10 min) Objective: - Discuss next steps Akbar - Are path names normative? Zach - Path names are arbitrary. Discover using interface description (if). Matthias - People might think that this is normative, but the basic principle is just REST. Matthias - URIs should actually be dynamic and not pre-configured (as that is the true REST principle from Roy Fielding and others from HTTP). Zach - probably need a section on "what is REST in IoT" * If we have time: (discuss in context of groupcom, core-interfaces and resource-directory) draft-ishaq-core-entities-00 (ipr) (10 min, Floris Van den Abeele) (No time) --------------------------------- THURSDAY, August 1, 2013 1300-1500 Afternoon Session I Bellevue APP *** core Constrained RESTful Environments WG ** Intro (5 min) Akbar: has updated the Group comm. draft since monday and asks for WGLC (Zach has reviewd it so far, Carsten will do so in the near future) Akbar: Will follow up wih Carsten on the mailing list to gently nudge the reviewers (i.e. Carsten) and keep moving the I-D forward to WGLC ** related activities Stefanie presents a quick summary of a CoRE AA lunch meeting Carsten: sizeable piece of work, do we have the energy for that? How many people attended the lunch meeting? Stefanie: 7 people Objectives: - explain shortly what the activity does and what was achieved as well as invite constrained network experts to join the relevant mailing lists. *** OMA M2M update (Zach Shelby) (3 min) Zach: An update of the work of one of our main external customers (OMA) for CoAP Zach: Next Plugtest in Nov in Las Vegas, free of charge! **** Congestion Control Update (by August) August presents preliminary results from simulations of basic CoAP congestion control and advanced congestion control based on an interpretation of the CoCoA draft. (see slides.) Zach: should focus first on the estimation of the RTO and look at NSTART > 1 later. Akbar: Which topologies were you using for MAC layer performance? August: Several Mulihop topologies, e.g. Star, Chain. but only one subnet Carsten: is there anyone else in the room working on this topic? (No one) ** open issues on drafts nearing 2nd WGLC (50 min) draft-ietf-core-block-12 Matthias: 1) ticket 253: don't like the server initiative because this requires extra code at the server. Carsten: this came to life due to the separate response. If you know how to keep the initiative at the client, please write this up to the ML. Matthias: 2) simplify the whole draft. argues that the draft should state a MUST for doing block transfer sequentially Zach: Good idea to simplify the draft draft-ietf-core-observe-09 Klaus: All tickets in this draft are closed. Two details left. Cancellation: Zach: Garbage collection is ok. Cancelation might be useful in TCP, Websockets etc Klaus: Goes over Liveliness solution options. Left: Token reuse and Ping/pong Zach: +1 Token reuse. Andrew: When having many observer --> many messages as well. -1 ping/pong Akbar: +1 Token reuse. Matthias: +1 Token reuse Kepeng: +1 Token reuse Floris: +1 Token reuse, clients could consider ETags to avoid overloading the network when re-registering 2 other people (names?) also came to mike and gave +1 for Token reuse Klaus: Some text in the draft is needed to specify how "patient" a client should be. Objectives: - close remaining issues in preparation of 2nd WGLC related: ** Links-JSON draft-ietf-core-links-json-00 (2 min) Carsten asks how many people have actually implemented this? 1 person raises hand. Carsten: We will have to wait bit longer and get more feedback from implementers, so this will have to sit for a while until that happens. * Alternative Transports (40 min) Encapsulation: Akbar - If we change headers is it CoAP that we are transporting anymore? Zach - It might be better not to change the headers but maybe just reserve the bits for the particular transport so it doesn't require multiple CoAP encoders on the receiver (N transports => N encoders, not wanted on constrained devices) Carsten- Think of it like header compression. Carsten: There is another draft about TCP. ????: how to map resoures between different transports is out of scope of the CoRE WG. Carsten replies: there will be some more slides on the URI issue in a second. Going to those slides now. draft-silverajan-core-coap-alternative-transports-02 (Switched to "CoAP URI: Transport representations" slide) Martin Thomson: did you discuss with the HTTP people on this? In HTTP2 we decided to use the exact same URI, the transport to use is signalled out of band. Silverajan: still work in progress. Zach: thinks the issue is different Thomson: resource identification is bound to the way how you contact the server. wants to point out that HTTP2 has some very early work on how to encode this type of information in DNS queries. Some people have some experience in this space, try consulting with them. Barry Leiba: if you're trying to re-use the media-type suffix for signalling the transport. Putting it in the scheme name, might require to register alot of scheme names (drawback). Pete Resnick: in the scheme where we do use the suffix for signaliing in how to contact the destination. Transport doesn't look at information inside the URI to contact the destination. Barry: comparison to HTTS from Pete is completely off though. HTTP drafts points to the HTTPS scheme, and HTTPS scheme was called into lift before it was necessary to register new scheme names * Bill Silverajan resumes presentation * Carsten: ??? * Bill Silverajan resumes presentation * Barry: likes the 2nd proposal, but coap scheme is already fixed in the soon-to-be CoAP RFC. Thomson: combining the 1ste and 2nd proposal could work ok. Changing the syntax of the authority would be ok. Zach: we should be careful how many schemes we want to define. +1 for the second poposal Akbar: how would be incorporate the security model inside the last proposal? Bill: We don't know yet. Barry: Make sure to contact the URI experts(Mark Nottingham, Julian Reschke) to review your URI proposals draft-becker-core-coap-sms-gprs-03 Thomas: any questions/remarks? Zach: exceptions to the rule that might need this, but we don't need this all the time. One case where we do use this, in case of observe we might need actually want a separate return path for the notifications. One use-case could be CoAP over cellulair broadcast. Thomson: sending the response to some other guy can have some serious security implications (e.g. DoS). This separate return path would alter the request/response semantics of the protocol. Zach: not needed except for observe notifications, but not for everything else. Kepeng: agrees with Zach. draft-becker-core-transport-scenarios-00 draft-softgear-core-coapa-00 draft-savolainen-core-coap-websockets-00 draft-ikpark-core-shim-00 * If we have time (discuss in conjunction with observe:) draft-li-core-conditional-observe-04 (10 min, Floris): Zach: It is indeed a problem. CoAP might not be the right place to define thresholds etc. Highly depends on representations Klaus: Its difficult to come up with one language that works for everything. Possible solution: Proxy to translate the different representations. Kepeng: It is a problem, but he preferes to use options. Carsten: Every media type will need its own condition definition. We need a more generel way of doing conditional observe. Zach: Disagrees with Carsten. That is the right place to do the media type things. (Out of time.)