Authentication and Authorization for Constrained Environments BOF WEDNESDAY, March 5, 2014 0900-1130 GMT Room: Balmoral BOF Chairs: - Kepeng Li - Hannes Tschofenig Note taker: Bert Greevenbosch 1. Introduction (Hannes Tschofenig) http://www.ietf.org/proceedings/89/slides/slides-89-ace-6.ppt 2. Constrained Node Network (Carsten Bormann) http://www.ietf.org/proceedings/89/slides/slides-89-ace-2.pdf Introduction to the general area of constrained node networks, and relevant problems/solutions. Constraints Scaling down in order to scale up Expected scale in the near future. Introduction of classes (class 0 for most constrained, to class 2 to not so constrained). Carsten argues that DICE should focus on “class 1 (quite constrained)”. Moore’s law barely applies, he says. He is convinced that the gains from Moore’s law are used to save power and cost rather than increase computing power. Battery constraints Network constraints, low power, high loss Code is expensive, state is expensive, packets are expensive and listening is expensive. Especially transmission costs require savings. IETF WGs related IoT/constrained environments: LWIG, 6Lo, 6TiSCH, ROLL, CoRE, DICE No group for OPS. Short introduction to Constrained Application Protocol (CoAP). Importance of security – need a robust system, especially since quick replacement of sensors/actuators may not be feasible. Some security parameters have been defined for CoAP, e.g. usage of SHA-256, AES-128, ECC (P-256), as well as DTLS as an underlying protocol. Authorisation format and workflow have not been defined. Question on whether ACE is exclusively for CoAP. Carsten wants to make sure it at least works with CoAP. Sean Turner (outgoing security AD): TLS and HTTPbis look at compression, and how security relates to it. How would compression and encryption work together? Carsten: compression does not work very well in this space, as we transmit little data. Compression also increases complexity, which may be too expensive. Header compression may be considered, but that is in another lower layer than DTLS. Tim Kerry: DTLS does not work for all protocols, e.g. it doesn’t work with SMS. Carsten: Agree! We are IP oriented. 3. Use Cases (Ludwig Seitz) http://www.ietf.org/proceedings/89/slides/slides-89-ace-3.pdf There are various drafts, Ludwig will present his draft, which was a collaboration and contains elements from the other drafts. Container use-case. Transport of bananas from origin to shop. Containers have sensors for location etc. Stakeholders include owner, storage company, transport company. Different access rights per stakeholder, at different times/locations. Access rights may need to be updated dynamically, depending on changing circumstances. Use cases Explicit rights for different stakeholders, fine-grained access control, local conditions, dynamic access control. Discussion: Max : do you think the train, truck of ship can be online whereas the container is not? What are the limitations of the off-line stuff? Ludwig: the transporters could be connected, but it is not assumed that the chip can be accessed at any time. Barry: requirement is that some things need to be able to work offline. There is also the requirement for role-based access control. Kerry Lynn: an adequate cover set for most relevant use-cases is needed. Don’t forget about devices in the wall. How about life-cycling, e.g. when the building changes owner? We need to consider this. Ludwig: we are looking forward to such input. Bob Moskovitz (Verizon): large things like boats and trains, you can reasonable assume they will have connectivity. Torsten Lodderstedt: which party will provide the network connectivity? Which type, Bluetooth, GSM, WiFI? Changing all the time? Ludwig: yes. Yuseke Doi: What actions are taken based on the collected data? Ludwig: when the bananas are rotten, the transport company can move its priorities to another transport. Hannes: As a summary, it might be good to add a few references to the scenario to offer more background context. We also have to think more on the off-line and on-line cases. 4. Architectural Design Choices (Göran Selander) http://www.ietf.org/proceedings/89/slides/slides-89-ace-4.pptx Introduction to a general architecture and terminology. Idea: want to facilitate communication between client and resource server (RS). However ,have an assisting parties (authorisation server (AS)) that helps the RS making authorisation decisions. Terminology was taken from OAuth, but this does not imply usage of OAuth for the solution. AS provides RS with authorisation information. Key management between AS and RS out of scope. Communication between AS and RS may take place over the client. Client may also have its own AS, for cross-domain pairing. Considerations: Need multi-party security protocol Session security or object security or hybrid? Symmetric or asymmetric crypto? Is revocation required or is authorisation info with short time validity sufficient? Discussion: Kerry Lynn: are we considering a multi-protocol security consideration? I.e. a proxy between CoAP conversation and TLS conversation. Göran: good question, need to discuss this. ??: which class of devices know the time? This question is related to the revocation. Carsten: some chips may have clocks, but many may not have clocks. A configuration without clock would be quite useful. Dave Robin: the lack of a clock limits offline authorisation. Offline use-case is very relevant though. Checking authorisation off-line is quite complex. Hannes: this is a trade-off decision. Good to consider. 5. (Preliminary) Gap Analysis (Hannes Tschofenig) http://www.ietf.org/proceedings/89/slides/slides-89-ace-5.pptx Hannes’ question: is there anything we can re-use? There have been tutorials on Kerberos, OAuth, PKI/Certificate Model and AAA. ABFAB model: use Radius for communication between AS and RS Gaps: - Real time-interaction between AAA server and RS - ABFAB architecture uses layering of EAP within the GSS-API, adding additional overhead - Binding for transport of EAP payloads in CoAP does not exist. Kerberos Client talks to AS, AS provides ticket to client which client forwards to RS. Gaps: - Each ticket is only usable for a single service - Kerberos uses ASN.1 - No standardised access control policy language. - CoAP bindings for KRB_PRIV and KRB_SAFE have not been defined. - Ticket and authenticator rely on symmetric keys only. OAuth Architecture Similar to Kerberos Gaps - Support for cross-realm interaction has not been standardises - A binding for CoAP does not exist - OAuth architecture does not standardise the authentication procedure of the resource owner to the authorisation server itself. - Profiling is needed PKI/Certificate model Use short-lived certificates Gaps - Certificate format and PKI use ASN.1 - No UDP or CoAP transport defined for CMC/CMP/SCEP or PKCS#10. - Relies on asymmetric crypto, not cheap! Need to agree on requirements first! Good stuff out-there, but preliminary analysis shows there is work needed. A venue for such dialog is needed. Discussion Ralph Droms: Gap analysis needs to go through entire lifecycle. Zigbee IP specification may be considered for the longer lifecycle issues. ??: will post link to Zigbee IP specification. Lionel: is there IP connectivity on client side? Hannes: Different proposals make different assumptions regarding connectivity. Justin Richer: lot of the diagrams are quite similar. The protocols are adapted to their environments. Best re-use may be in the patterns and structures, rather than the complete protocol. Samita Choclaburty: this is much needed work for deployment in the next phase. Is IPv4 in consideration? Hannes: IPv6 is assumed. The IETF IoT work is IPv6 centric. Sam Hartman: there are some domain specific issues, so conceptual re-use may be appropriate. Also some fears: it may be quite challenging to do the security analysis. Re-using credentials in constrained and non-constrained environments need to be considered. Much value in re-use. So re-using code and specifications and security analysis should be done as much as possible. ??: think of applications such as RFID, and reach out to relevant groups. Hannes: yes, reaching out is good, but it must not be an infinite process. Zach Shelby: agree with Sam, we need to re-use existing working protocols, terminology, security analysis. We miss the point that we also talk to bigger things. It needs to work with e.g. phones too. Don’t believe in usage of only symmetric crypto; all chips can do already asymmetric crypto. Now in software, in the future in hardware too. Network scalability is more to consider. Last concern: wrong area. Should not be in the applications area but in the security area. Robert Cragie: agrees with Zach about asymm crypto. Scaling important, but need to consider home use cases too. For deployment it should be simple to the user. Michael Richardson: maybe a new area is needed? But it doesn’t matter in which area, as long as we have good chairs and people participating. Do you think there will be e.g. an OAuth system that uses a mechanical proxy to connect to a constrained device? Barry Leiba: real key is getting the right people. Which area will be decided later. Bob Moskovitz: C0 devices also need security too. Highly interested in a solution to very low-end devices. Zach Shelby: too deep in solution space; IOP with OAuth is too early to discuss. But we are in REST world, so proxying is certainly in scope. Bill Mills: focus on HTTP on constrained environments is wrong. Make sure things work across transport protocols, i.e. OAuth is based on HTTP, but to expand it to CoAP may be a consideration. Consider scaling! Billions of devices… Authentication tokens should be more useful than just HTTP. Hannes: CoAP is in scope. Maybe good to look. Dave: as soon as you talk about authentication, the RS has the trust relationship with the AS, not with the proxy. It should be end-to-end security! Hannes: good point to consider for use-case discussion, e.g. especially on the role of proxies. Derek Atkins: you can compress before encrypting. Bootstrapping problem: how does the fresh device (that never had communication before) know you are authenticated to contact it? Hannes: bootstrapping has a lot of meanings. We consider it out-of-scope, but it needs consideration in another context. Derek: it is not just keys, but also etc. initial ACLs. Zach Shelby: OMA LwM2M does that. It needs to be synchronised with IETF specs. Leif: there is some work in ??? on this. Sam Hartman: bootstrap considerations need to be in scope. When it comes to security it is really about end-to-end trust. IOP is important. Proxies across security area tend to be universally trusted. Michael: if we want IOP between OAuth etc. we end up with a trusted proxy. Or the other side needs to somehow be able to validate the other protocol. Prefer to keep that out of scope, but be aware of it. Carsten Bormann: there were a number of proposals about bootstrapping, such that it fits with what we are doing here. Good to make sure these approaches exist and work, but it should not be part of the consensus effort of ACE. We need to consider the role of “wiser elders”, i.e. the Ass. Charter Discussion (Kepeng Li) Charter text summary: - Standardised solution for authentication and authorisation - Authorised access to resources - Use CoAP and leverage DTLS security, where possible - Employ additional less-constrained devices in order to relieve the constrained nodes - Existing authentication and authorisation protocols are used and re-applied. Restricting the options within each of the specifications - Operate across multiple domains. Task list: 1. Document use cases and requirements 2. Define profiles for encoding authentication and authorisation data 3. Document design criteria for the required security protocols with respect to resource usage 4. Define a mechanism for authenticated and protected transfer of authorisation information suitable for constrained environments 5. Define format for access tokens and for authorisation info that are suitable for constrained devices 6. Define bootstrapping for authorisation information using the resource directory. DISCUSSION: Hannes: couple of requests on provisioning/bootstrapping. We should keep it in mind, but it doesn’t need to be a milestone. Sam: strike the task “encodings of authentication and authorisation data”. We need to have the use-cases and requirements talks, but it may not require published documents. Scope to CoAP and DTLS. Justin Richer: requirements should not be gating function for good work. Discussion on requirements is important though. Concerning connectivity: would the “wise elder” always have connectivity? Or should the overall system be considered to solve the problem? Leif: scoping it to CoAP and DTLS is a good idea. Give clear constraints in the charter. No. 4+5 could be combined. Wendy Seltzer: should consider web architecture. Zach Shelby: agree with charter comments. Remove 1,2,3. Combine 4+5. As author of resource directory, Zach doesn’t understand point 6. Hannes: I don’t know about point 6 either. Olaf Bergmann: don’t want to change RD functionality, but define attributes to be used in RD, such as defined in DCAF draft. Zach Shelby: why? What do you want to discover? Or how to access a resource? Olaf: just to find the URI that the client has to use to ask for an authorisation token. Hannes: point 6 seems to need consideration. Kerry Lynn: excluding TLS and HTTP would e.g. orphan Zigbee over IP. Not sure if we have a lot of operational experience with CoAP over the internet yet. Tim Garry: DTLS doesn’t work over SMS. We need to consider bindings. Carsten Bormann: resource directory interface is needed. But it may not require a point; it is small. How to get this work done? There is a lot of interest already. We should start the work. Best start making technical proposals! Hannes: yes, but the conversation about requirements and challenges is important! Rajeev Koodli: it is not clear whether it is an online or offline case. That should be clarified. Also which party is constrained? Server only, or also client? Hannes: true. Needs work. Rajeev Koodli: maybe RS is less constrained than client; it needs to talk to AS after all. Max: maybe combine task item 4+6? Better not try to pick technologies in advance. Charter Question a) Is this a topic the IETF should try to address? b) Is this a topic the IETF should not try to address? Strong support for (a). One person against. Hannes concludes there is support. Barry: why against? Ralph: I don't like that the charter is focused on CoAP&DTLS. Hannes: we need to keep some limitations on scope. SMS may not be that easy. Kerry Lynn: limiting this to DTLS and CoAP is not appropriate. Hannes: initial focus should be use of CoAP in DTLS, but other bindings for CoAP and other transport would be possible later. Reasonable? Sam: no, let’s restrict to CoAP & DTLS. Don’t want SMS case in scope. Hannes: Restrict scope to CoAP & DTLS, yes or no? Response: 50/50 Barry: requires more charter discussion. Margaret: DTLS may not always be required. As long as authentication is properly considered. Barry: this discussion needs to be on list. Leif: proof that you don’t need confidentiality. Barry: on the list. Engagement: a) How many are willing to review? 30 b) How many are interested to work on documents? 15 Pretty good numbers. Barry: clearly a lot of interest in working on it. Barry: asks Stephen and Kathleen (SEC Ads) for comments: Stephen: the higher the confidentiality the higher the probability it gets chartered. Hannes: Margaret will give tutorial on APPSap. Kathleen: scope matters. Hannes: We will continue the charter discussions on the list.