Minutes from IETF 81 Note well well noted, blue sheets distributed. Volunteers for note taking. 1. Link format. Last call was January. Chairs to do writeup. 2. CoAP: Reminder of changes made. One open issue regarding Content-Type Negotiation. Do we support single or muliple Accept requests? What about error return? We decide to keep it elective, and if multiple types are requested and none are implemented, a server that supports Content-Type Negotiation returns an error code. Servers that don't support Content-Type Negotiation will simply return content in the single format they do support. Security section: let the pre-shared key mode stay as is, Have an interim meeting; maybe Sept. to nail down cert provisioning story. Prefer not to have it during Sept 18 IEEE 802 meeting in Okinawa (Bob Moskowitz). Pero (spelling?) will write a proposal before September. Bob Moskowitz suggests the use of raw public keys in ACLs rather than x.509 certificates. Bob Moskowitz will write up a proposal for doing that. "TLS working group should take up a raw public key mode." (hum - unanimous agreement). Blockwise Transfers in CoAP: needs rewrite, better names for BLOCK1, BLOCK2 and clarify that Request Entity Too Large could mean truncated message. (Shelby will open ticket on the latter.) Observe: Same version as in Prague. Text on reordering detection needs rewrite for clarity. Observe relationship used to contain a duration negotiation, but simplification caused us to drop that. Requesting observation relationship to a sleepy server can be difficult. Proxy Implementation Advice: Request for group to provide examples for TLS+Proxy to CoAP. Request to group to read and comment on mailing list. Sleepy nodes: Shelby to clarify retransmission rules. Arkko says that observe needs to be fixed for low power networks. Always Online requirements: presentation given. :: resource directory shelby :: personal draft start specifying interfaces of resource directory roughly comes from SENSEI EU project migrated to CoRE in hack fests used as a commodity to locate resources in a simple way architecturally endpoints make their web links available to others by registering to an RD clients lookup in the RD for resources given ct= and other attributes the draft only wants to specify the (REST) interface of the RD, not how it is implemented internally 1) discover RD via .well-known 2) register POSTing resources to a "root" pathname given by the RD during discovery 3) update by PUTing the up ... 4) validation [see slides] 5) deletion [see slides] 6) lookup [see slides] two new link format are defined 1) ins= for distinguish different res with the same rt= 2) exp for allow the RD to export the request you have registered issues terminology is a mess how to differentiate between multiple RDs in discovery how to tell the RD about the host hannes > trying to give meaning to the nice Architecture picture in the presentation shelby > just want to propose a basic mechanism for registration and lookup, no over specification :: discovery mapping by lynn :: -01 refers to core charter, how to map existing technologies use cases support alt methods for discovery in mixed envs (e.g. http and coap clients coexisting) support hierarchical discovery in massively populated envs use: DNS-SD for coarse grained discovery link-format for fine grained discovery DNS-SD uses SRV records to get service instance name (host:port, the server at the transport layer); then use TXT record to add pairs "path=entry-point" (the resource at the application layer) mapping link-format to DNS-SD ins= -> {Instance} rt= -> {Service} -> TXT.path=... alex > concern about overloading the TXT record, have you looked after alt solutions ? fluffy > we are reusing DNS-SD, so nothing has been invented here slide with example of link-format to DNS-SD mapping coap query to the well-known at the all-multicast-hosts address for core "exportable" resources get a response back, do reverse DNS on the responder address and create a DNS record ... [see slides] :: groupconn by akbar :: -06 * basic mcast concepts definition - assume multicple receiver nodes in a group - sender sends a single message with content to the group address - actual message distribution (can be mcast, series of mcasts, serial unicast, ...) * reqs for group comm [see slide "Requirements for Group Comm ([1-4]/4) for details] - reliability - efficiency - low latency - synchrony - ordering - security - flexibility - robust group management - network layer independence - minimal spec overhead - minimal impl overhead - mixed IP backbone/LLN topology support * potential approaches - IP multicast - overlay mcast - application layer group management (a la mailing list) * recommendations - adopt IP mcast as baseline solution (not a trivial task, but does not require changes in the IP mcast suite) ACTION: send to the homenet group the mcast requirements - MLD-like optimizations, e.g. subset akbar > what next ? fluffy > not ready to take any decision lynn > does the core draft needs on the method side support groupwise communication ? shelby > congestion control needs to be expanded, the rest of the spec seems to be IP multicast ready :: timeout options :: POST/PUT issue {slide 1} GET issue {slide 2} => add the size option to solve the highlighted issues - GET: server return the size of the resource without giving back the payload - POST/PUT: ... open issues on proposal (going on in the ml): * elective or critical ? * block[12] design fluffy > [after humming] ok, carry on with the document request-timeout option to specify timeout in the request open issues on proposal (going on in the ml): milli or mib secs for timeout spec ? difference between request and connection timeout fluffy > comments ? shelby > not convinced that we need this, but not an horrible idea. get real-world experience to have a proof it is not broken before adopting it as wg item fluffy > thanks for being the first in the history of this wg to close your presentation on time :: naming and discovery of groups by vanderstok :: how to represent in the DNS-SD inherently hierarchical/groupable devices by defining the hierarchy in the SRV name space... shelby > issue with forcing all the res in the group to use the same path vds > we didn't shelby > use proxy to resolve the conflict ... > where is the DNS and who is administrating it ? lynn > delegate the IT guys the administration in some "secure" way shelby > I think the idea of forcing the sensors in the group to have the same path should be carefully considered. An alternative way is to have a proxy in between. Peter > Put the proxy in between will cause delay. Ed > Where the DNS server is? Who is administrative it in that scenario? Kerry > In commercial applications, you can delegate DNS resource. Anders > For large buildings you will have administrative DNS server. Kerry > It is also possible to add DNS records in existing DNS. :: EAP-based key establishment by ohba :: goal: provide KE mech for - DTLS-PSK - PSKmode for IKEv2 use cases: - non integrated with network access auth - integrated with network access auth architecture picture { see slide } basically you need two functional entities AA (auth agent) and AS (auth server) [maybe hosted in the same network device] to handle the KE protocol and credential feeding on endpoints configured parameters at the end of a successful KE process: - identity of client and server - PSK to use in DTLS of IKEv2 to setup SAs support for change of service provider (recommissioning): with the use of service provider-independent authentication credentials that may be pre-provisioned to the UE (e.g. manufacturer provisioned credential). ... > recommends thinking about different mech that reduces the number of messages used for KE (12 or so) :: deploying security by arkko :: for multiple reasons (# of objects, no user interface, ...) provisioning is the fundamental issue another issue is the layering one: LL security is not enough in non isolated contexts, ... concepts: * secure identities: hash(public_key), like in HIP * provisioning: each object has a secure identity that is communicated to the server * layer choice * proto formats how identities are used: messages are sent with data, signature, public_key of the sender, secure_id ohba > no mutual auth in this sec model arkko > it is modeled after my current setup, which doesn't look for server identity hannes > there's probably no security solution that satisfies everyone. we should probably make a bigger picture rather than provide single-shot solutions arkko > mine is a minimalistic approach that aims at using the minimal amount of resources possible for doing what i need... ekr > ... oscar > DTLS is more efficient from a memory and message size arkko > provisioning is not cheap in DTLS bob > use 2D barcode to do the provisioning Yoshihiro > his identity is the client device identity. Consider the mutual authentication, how this can be done? Hannes > he different trust model leads to different solutions. This is the application layer solution. I am wondering how this can form a big picture for different trust models in terms of standardization. arkko > We are proposing architecture that provides a practical, minimal-configuration approach to smart object security.