CoRE WG @ IETF88 (Vancouver) Minutes draft version 0.1. Chairs: Andrew Mcgregor Carsten Bormann Thanks to the notetakers: Carsten Bormann Corinna Schmitt Olaf Bergmann Matthias Kovatsch Thomas Fossati From these notes, compiled by Carsten Bormann. [Times/numbers in brackets indicate approximate position in the audio recordings and slide number.] MONDAY, November 4, 2013 1450-1720 Afternoon Session II Georgia B APP *** core Constrained RESTful Environments WG http://www.ietf.org/audio/ietf88/ietf88-georgiab-20131104-1450-pm2.mp3 ** Intro, Status etc. (10 min) 14:50–14:55 Intro [~01:00..09:00, 1-10] Note-Well, Blue Sheets, Scribes, etc. WG Status: - in RFC editor processing: draft-ietf-core-coap-18 - old and new Milestones Introduction: - Where are we standing - Overview of WG Documents and their standing - Agenda overview for Monday and Thursday * 2nd WGLC post-processing ** Observe (Presenter: Klaus Hartke) 14:55–15:25 -observe (KH) [09:20..35:40, 12-18] draft-ietf-core-observe-11 (30 min) WGLC completed 24:00 PDT on Tuesday, October 29, 2013. Active discussion of some remaining issues on the mailing list. Objective of slot: · Make decisions on remaining discussion points Observe (Presenter: Klaus Hartke) - draft-ietf-core-observe-11 (30 min) - editorial issues where done - 5 high level changes are now scope of work - Cancellation: Do we need an proactive mechanism in addition to the reactive one? Q by Zach Shelby: Telecommunication guys might be afraid of not being in control of cancellation. One solution was cancellation by using the same token. A: two options exist: reusing tokens without observe option or explicit cancel-observe mechanism Q by Bert G.: Can you use every GET-request? Does any reuse of the token cancel? This would resolve most of the issue. A: solution is implementation dependent. I have to look on details. Discussion will follow on mailing list. Q by Akbar: I think we need proactive cancellation. Define it and remove implementation notes? A: Its in addition within the draft. --> Yes, we should add this - Token lifetime: Just not reuse them? Q by Klaus H.: Can we solve the problem by not reusing tokens A by Zach: YES Comment by Carsten B.: Implementation note to divide token space into normal and observe tokens could help --> Should advise careful/safe token usage - Inadvertent token reuse: What should the server do? Q by Klaus H.: Do we need to place thing on the server? A by Zach: Just need to provide a little implementation advice here. - Intentional token reuse no comments --> Disallow except for refresh and maybe cancellation - Notification supersedure Comment by Zach: Problem when CoAP is implemented on an external network processor, but sometimes you might need updates ASAP (depending on application). So allow both options (make B [18] a may). Comment by Akbar: It will always require time until server and client are synchronized (eventual consistency) Comment by Bert: What happens when combined with block? This could also cause very long times until a representation is transferred. --> Carsten: So Klaus will implement these changes, finalization via mailing list, no 3rd WGLC. Submission to IESG soon. * Preparing 2nd WGLC ** Block (Presenter: Carsten Bormann) 15:25–15:45 -block (CB) [35:40..57:20, 20-27] draft-ietf-core-block-14.txt (20 min) Remaining tracker issues cleared by -14. Objective of slot: · Are we ready for 2nd WGLC? Block (Presenter: Carsten Bormann) - draft-ietf-core-block-14.txt (20 min) - The critical section problem Comment by Klaus H.: Client and server may have different idea about cache key because of unrecognized safe-to-forward options. Carsten: Request URI is always part of cache key. But good point, that needs to be clarified. Minutes comment by Matthias: The origin server might simply ignore the query and cannot differentiate requests through this. Q by Carsten: Who has an implementation of any part of the Block protocol? A: 6 raised hands --> Carsten: Keep general mechanisms of -14 and refine explanatory addition on the critical parts * Preparing WGLC ** Groupcomm (Presenter: Akbar Rahman) 15:45–16:00 Groupcomm (AR) [57:50..73:20, 28-33] draft-ietf-core-groupcomm-16 (15 min) (Background reading: draft-dijk-core-groupcomm-misc-04 (0 min)) Objective of presentation: · Summarize updates since last IETF (i.e. Rev. 12 – Rev. 16) · Discuss the recent comment from Peter to be able to selectively delete individual group memberships from an endpoint. · Request start of WGLC (if there are no more comments from the WG) Groupcomm (Presenter: Akbar Rahman) - draft-ietf-core-groupcomm-16 (15 min) - Comments on ticket #354 Q by Carsten: Looks like a good collection-style API now. What is the level of recommendation we attach to it (expectation, example, ...)? It is, for instance, done differently in OMA. Comment by Zach: It is optional, but we should recommend to do it like this for dynamic commissioning. OMA could represent this in an OMA object. A: We do mention it is optional. Does this cause a conflict? Zach: We would be in trouble if this were meant to be *the* interface. But we could recommend it some more for reading the information. Comment by Carsten: If limited to reading it looks like a management interface (see other WG). A by Zach: Might be overkill since this is very simple. - Any other updates that should go into the document? It should be made clear that this is about unreliable IP multicast. Comment by Carsten: This also applies to Trickle multicast in ROLL, which is a bit more reliable than IP multicast. A by Akbar: Will check with Esko. - Document ready for WGLC? Comment by Carsten (as chair): Address the currently open issues and then we can go for it. * other WG drafts: ** HTTP-CoAP Mapping (Presenter: Akbar for Salvatore Loreto) 16:00–16:15 HTTP mapping (SL) [72:20..97:10, 39..50] draft-ietf-core-http-mapping-02 (15 min) (Background reading: draft-castellani-core-advanced-http-mapping-02 (0 min)) Objective of presentation: · Review selected HTTP-to-CoAP URI mapping technique · Discuss open tickets HTTP-CoAP Mapping (Presenter: Salvatore Loreto) - draft-ietf-core-http-mapping-02 (15 min) Comment by Zach: Make scheme optional. Do not overload /.well-known/core, rather use a resource-type (rt). Comment by Zach on slide 44: use examples combination of point 2 and 3 Barry: Make sure not to reserve path-names (clear with Zach's comment on rt now). Comment by Kerry Lynn on slide 42: confusion of browsers might happen, colon is kind of reserved... Barry: Check syntax compatibility Q by Klaus Hartke: Implementation by proxy or client? A by Akbar: Proxy only Comment by Carsten to slide 42: URI template is subject of resource discovery Comment by Klaus Hartke: Responses can also can have relative URIs. Specified resolution algorithm does not work here, so we would need to reinvent a new one. Comment by Zach: it is interesting to use template discovery, put a template in a link Q Thomas Watteyne: How do I encode a non-default port? A: --> see draft Carsten: How about looking at the appendix [46..50] - Target URI encoding Comment by Zach: Prefer option #1 since there is no real parsing overhead and proxies are mostly unconstrained anyway. ** Discovery (Presenter: Zach Shelby) 16:15–16:30 Resource Directory (ZS) [97:11..118:10, 51-58] draft-ietf-core-resource-directory-00.txt (15 min) Objective: · Assess level of interest for proposed additions [Alternative Transports moved to Thursday] Discovery (Presenter: Zach Shelby) - draft-ietf-core-resource-directory-00.txt (15 min) - Web application support Q by Akbar: Does CoRE Link Format support the new relations for Web applications? A by Zach: Yes, RFC 6690 supports anchors etc. Klaus: Expressing metadata on links is also done in Turtle (RDF-based), so be careful about reinventing things. A by Zach: Web Linking has been around for a long time, so who is reinventing what... Erik Wilde: Turtle is just one serialization of RDF. A link is context + target. Both Turtle and Web Linking, are valid frameworks. Links allow clients to follow a goal; in RDF you don't have that goal. A by Zach: A lot of links where the context is the same. We can store almost everything in Links (e.g., serialized data). Comment by Carsten: We are not chartered for this work at this point. A by Zach: Being more explicit about JSON links for the RD is already enough to help them. - OMA queue mode [56-57] Comment by Akbar: Agenda item for sleepy nodes is related to this and there are also other mechanisms such as the mirror proxy. Q by Carsten: What are the next steps? A: we can close the known issues, I'm prepared to spin a new version including examples, documentation, interfaces, implementation issues; get some more implementation experience Comment by Carsten: Chairs made a mistake by making it an WG Document before the rechartering work --> solution: re-chartering --> prepare text (Alternative Transports (Presenter: Klaus Hartke)) - draft-silverajan-core-coap-alternative-transports (30 min) - Is shifted to Thursday, because of request for more preparing time. * If we have time: ** Avoiding responses to POST and PUT 17:00–17:20 No-Response (AB) [118:30..148:50, 61-70] draft-tcs-coap-no-response-option-04.txt (20 min) Objectives: · Is there interest in this function? · Is the proposed option the right way to solve it? Avoiding responses to POST and PUT - draft-tcs-coap-no-response-option-04.txt (20 min) Comment by Kerry Lynn: Confused by using POST, typically you use path of parent resource and get back a link, so you don't care about that? A: every POST creates short-lived resource with a query (e.g., to write into a database), which is not of interest to the client. Q by Klaus Hartke slide 65: Response suppression has been around for a long time, thanks for writing this up. use-cases are perfect for observe. Why do not use observe? Congestion control and orphan detection must be dealt with again. A: Thousands of active observe relationships are expected problematic for the central entity. Q by Klaus: Maybe use the existing observe notifications in conjunction with a new registration mechanism? (e.g., implicit registration on boot-up with pre-defined relationship) Comment by Carsten: There is a duality here. Devices saying something about themselves is usually done with observe. But a device wanting to control some other resource also may want something like eventual consistency. We have to add observe mechanisms to make this work. Question is if it is a concern of sender or receiver. Different status of activity might occur. We need to add more mechanisms known from observe, such as sequence numbers, to make this work. Klaus: Define interaction with caches; cache invalidation normally happens in responses, doing that through requests must be checked Bert: It is hard to make assumptions when filters are active: maybe it was successful or the error response was lost. A: Application-specific, so no standardization here. ?Results of Carsten's poll (who has read the draft, etc.)? 3-4: right approach --> Some support from WG to go on with work and pick up the comments THURSDAY, November 7, 2013 1520-1720 Afternoon Session II Regency B APP *** core Constrained RESTful Environments WG http://www.ietf.org/audio/ietf88/ietf88-regencyb-20131107-1300-pm3.mp3.download Access Control/Authorization in CoAP - Summary of AA goals/activity (Bert) Zach: RPK not missing authentication since it is based on public/private keys, only commissioning is not defined. Bert: you do not bind an identity to the presented key Carsten: It requires out-of-band authentication (see oob draft). - CoRE-AA meeting summary (Bert) most of the proposals see a (trusted) third party assisting the constrained devices in performing AA tasks Defined work to be done and assigned people (see slide) Need expertise and proper reviews - CoRE security use cases summary (Ludwig) Reporting the informal meeting held on Tuesday Consensus on Merging existing use case drafts and use case sections from the solution documents Focus on device-to-device security (device-to-service covered by OMA) Align with DICE use cases - Transport meeting summary (Stefanie) Mainly build on "big brothers" that do work for the constrained devices tricky scenarios where security domains are segmented and there's a need to bridge them Consensus on merging PSK-based and PPK-based drafts Q by Akbar: What is the atomic thing to authorize? A by Olaf: Authorize actions on resources (fine-grained resource-level authorization) A by Stefanie: Easy-to-do binary authorization, but also fine-grained authorization A by Ludwig: Device should be able to decide whether to do an DTLS handshake or not based on authorization Bert? Proceed with easy things first C by Zach: Would be a good way to go for simple howtos, e.g., how to handle DTLS tickets A by Stefanie: Merge first and then have different solutions (simplify understanding to "external" audience, and even for different authors) C by Zach: Be sure about whether we really need everything A by Carsten: Make sure that there are common parts and not only single solutions - CoRE AA: Low-hanging fruits (Zach) Need to add the descriptions that are missing in the CoAP base draft: How to handle certificates (e.g. authority name), issues for SubjectAltName (no OID yet defined), RD and DICE Profile need this How to do peer-to-peer authorization C by Yoshihiro Ohba: This might be out-of-scope for the IETF, but yes OAuth does this as well so we might need this A by Zach: Not really out-of-scope since also HTTP was struggling with this. If people ask for more, we might need a whole framework Q by Bert: Is DICE going towards X.509 A by Zach: Although we defined RPK as must implement, we see a lot certificate use in industry. DICE is not about auth, but what needs to be implemented of DTLS. Sandeep: SEP 2.0 also uses certificates. How do they deal with them? Don Sturek?: Only define ACLs and use certs for authentication -- problems with very constrained devices that cannot deal with CRLs and OCSP - What needs to be standardized (Carsten) Use cases and maybe authorization payload in CoRE. Multi-party transfer of authorization (e.g., jennings-core-transitive-trust-enrollment) is a security problem, so needs another WG. X.509 profile might go into DICE. All of this required in RD. Q by Zach: What exactly should go into RD? A by Carsten: Nailing down the things such as how to use the fields. Q by Bert: What do you mean by authorization payload, is it the ticket? A by Carsten: The ticket will be the envelop of this payload. The payload tells you what is authorized. Point 3 of the slide is about protecting the ticket. C by Carsten: The IETF should not define the architecture for this. Use cases can be about the bigger picture. C by Zach: Authorization payload (ACL format) must be kept flexible, e.g., different serializations. Q by Akbar: Is this a sparse version of OAuth? A by Derek: OAuth is about the tokens to pass authorization around and can help. C by Carsten: OAuth is made for the "big Web," though. Q by Olaf: Is trust-enrollment not about bootstrapping? A by Carsten: Yes, but also about moving authorization around. C by Bert: We need more discussion before scoping the work like shown on slide 105. - Current charter Need re-chartering for RD, so we can also check security-related chartering, e.g., for JOSE Zach: Attempt to include X.509 Profile Bert: is X.509 profile in scope with CoRE? Zach: see CoAP-18 section 9.1.1: we just miss some small bits that we decide to left out because of lack of man-power Derek: Focus on implementation issues, how do the keys get into the devices Barry: Talk to the people in HOMENET as they have very related problems Sundeep: Maybe update the 2099 milestones (which we used for "parking") Zach: Industry systems often have their own frameworks, want certificates, etc. Michael Richardson: Why is trust-enrollment not in the charter when bootstrapping is in the charter? Carsten: Text in the charter was intended for network bootstrapping. Don: SEP 2.0 uses thumbprint of certificate for network bootstrapping, but is partly PANA-based. Zach: Bootstrapping issues were not clear when chartering the WG. By now many went on their own, since we did not provide a solution. We need to figure out what people need. Carsten: Is there anything we do not want to do from slide 105? Zach: Point 3 is scary. Maybe look towards OAuth to break it down. --> No major objections. Turn bullets into re-charter proposal and submit to Barry/IESG OMA M2M update / Plugtest (Presenter: Zach Shelby) - OMA Lightweight spec is final now - Plugtest in Las Vegas, 19-22 Nov 2013, it's free! Barry: Will people use OMA Lightweight? Zach: Yes, operators do for instance. ??: URI for test specs and more information? Carsten: Will post it to the list. Alternative Transports (Presenter: Klaus Hartke) Sandeep: Why are there no security issues mentioned for Alternative Transports? Klaus: Every individual transport must look into this. - URI issues Barry: The new proposals start to look nice. Do we really need a new scheme? Klaus: coap:// scheme is already defined and cannot be changed. Barry: Have you talked to URI experts? Go and check with Mark Nottingham and ? Klaus: Yes: one was in favor of coap+x, one proposed coap-at:transport?coap://... ?? Klaus: Could also be put into DNS, but we want an independent approach. Carsten: CoAP spec leaves open how to get this and so CoAP does not rely on DNS Thomas Watteyne: On what format do you relay on? Klaus: ?? Kerry Lynn: Introduce some constraints on the endpoint identifiers. Carsten: Missing alternative is using regname with semicolon. Only problem is with existing URI parsers. Klaus: We tested different formats with multiple parsers. Thomas Watteyne: Why coap-at scheme? -> coap scheme already defined in specs *out of time* LocalWords: Carsten Zach supersedure CoAP IESG Bormann ietf URI API LocalWords: Groupcomm Rahman groupcomm OMA multicast Esko WGLC URIs LocalWords: Loreto Hartke Watteyne CoRE metadata RDF JSON DTLS OID LocalWords: SubjectAltName Yoshihiro Ohba OAuth RPK ACLs CRLs OCSP LocalWords: ACL Plugtest DNS parsers