ACE WG IETF 101 Monday March 19, 2018 0930h-1200h Note Well and Agenda Bashing ============================ presenters: chairs slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-chair-slides-00 The chairs provided an update on the status of the working groups and its drafts. Comment: (Hannes Tschofenig) There is a related meeting, ATLS, at lunch today. I'll send information to the mailing list. The background is as follows -- https://tools.ietf.org/html/draft-friel-tls-atls-00. Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) ============================================================ draft: draft-ietf-ace-cwt-proof-of-possession presenter: Mike Jones slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-cwt-proof-of-possession-tokens-00 Jones summarized the changes made to -02 based on review comments. The editors believe that this draft is ready for WGLC. EST over secure CoAP (EST-coaps) ================================ draft: draft-ietf-ace-coap-est presenter: Peter van der Stok slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-est-over-secure-coap-00 van der Stok summarized the changes made in the -00 version and identified open issues. BRSKI modes https://trac.ietf.org/trac/int/wiki/EnrollmentRoadmap Q (Hannes Tschofenig): Can you explain server key generation? This might not be a good practice. A: (van der Stok): We received feedback (Panos Kampanakis) that this was important. The transport protects it. A: (Max ) The server key generation was brought it to support RPKI mechanism A: (van der Stok) So you believe this use case should be better explained? A: (Max ): Yes. Comment: (Tschofenig): You might want to keep CoAP response codes separate -- not as a normative reference in the draft. It would be better to get things out into deployment. Protecting EST payloads with OSCORE =================================== draft: draft-selander-ace-coap-est-oscore presenter: G?ran Selander slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-protecting-est-with-oscore-00 Selander summarized the changes in this rewritten draft that should now better aligns with EALS. Q to WG (by Selander): Was this the change you wanted? Q (Kaduk): Who has read the draft? A: [6 - 8 people] A: (Kaduk): More people need to read it Authentication and Authorization for Constrained Environments (ACE) =================================================================== draft: draft-ietf-ace-oauth-authz draft: draft-ietf-ace-dtls-authorize draft: draft-ietf-ace-oscore-profile presenter: Ludwig Seitz slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-ace-authorization-and-authentication-framework-and-profiles-00 Seitz summarized the changes from -08 to -10 of draft-ietf-ace-oauth-authz. Seitz summarized the changes from -02 to -03 of draft-ietf-ace-dtls-authorize; and identified next steps. Comment (Hannes Tschofenig): I like the work on curve Ed25519, but it might be a rush to make it mandatory. Perhaps make it optional. A: (Olaf Bergmann): I added it because no one objected in Prague A: (Schaad) What are the MTI for TLS v1.3? A: (Tschofenig): I created a profile that mirrors TLS v1.3. However, many of these are not currently implemented in IoT because the hardware is likely not ready A: (Kaduk): A: (): If we don't mandate Ed25519 now, they when? What would a transition phase look like? A: (Tschofenig): Agreed. However, it would be bad that no implementations would support it. A transition phase would be helpful. A: (Seitz): The positive of making it MTI, that would force implementation. A: (Carsten Bormann): MTI might be less useful in this environment. We should start a concerted effort to revisit all algorithms specified, almost like a CURDLE process. A: (Olaf Bergmann): +1 on review of crypto algorithms. There are open source implementations. It makes sense A: (Seitz): We also need to get it (ed25519) into the DTLS libraries. It may take a while. A: (): +1. Other curves are already in and added to libraries. What is our goal in making this curve MTI? It may present a barrier to adoption. A: (Kaduk): We need to take this algorithm discussion to the list. A: (Seitz): A decision would be helpful here. A: (Bormann): What would that mean? A: (Seitz): Which curves should be MTI? A: (Bormann): This decision will require coordination -- this isn't an ACE decision alone. A: (Seitz): Coordinate with whom? A: (Bormann): For example, CORE. Comment: (Seitz): We need more review. Seitz summarized the changes from -02 to -03 of draft-ietf-ace-oscore-profile. Q: (Seitz) Any volunteers to help with Token Binding work at OAuth? Hannes Tschofenig and John Bradley were volunteered. Q: (Seitz) Is there a (or do we want a) relationship to the OCF work? A: (Dave Taylor): There was a meeting in Prague on Friday on OCF. We will be discussing how to coordinate across SDOs. A: (Kaduk) Was there also a virtual meeting earlier? Did something interesting happen? A: (Bormann): We are holding coordination meeting every 6 months. ACE security work and OCF is a known issues, but has not been resolved. Q: (Seitz) to WG: Should we do a WGLC? A: (Tschofenig): I think it would be good to do a WGLC soon. We need better prototype implementations, especially open source, to help. Q: (Seitz): Hannes you promised a paper on the analysis of the client token functionality. A: (Tschofenig): the paper is published -- http://st.fbk.eu/sites/st.fbk.eu/files/osw2018-ace.pdf. Additional relevant papers can be found at https://st.fbk.eu/osw2018/program. Q: (Kaduk): Who wants to see the client token work continue? [room is quiet] A: (Goeran Selander): There is missing functionality related to client authorization -- the data going to the client about what it is supposed to do. For example when you authorize keys for group communication. The chairs plan to discussion when to conduct the WGLC offline. Key Provisioning for Group Communication using ACE ================================================== draft: draft-palombini-ace-key-groupcomm presenter: Francesca Palombini slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-group-key-provisioning-01 Palombini introduced draft-palombini-ace-key-groupcomm -- scope and Q: (Seitz): Per slide 3, you noted that the KDC doesn't exist in ACE. I believe it does. A: (Palobinia): Yes, it does, but the flow in slide 5, does not. Q: (Bormann): What is the claim made about the public keys in the KDC? A: (Palombini): KDC will store and distribute the public keys. The draft does not specify how these keys are used. A: (Bormann): Understood. We should specify this somewhere. CoAP Pub-Sub Profile for ACE ============================ draft: draft-palombini-ace-coap-pubsub-profile presenter: Francesca Palombini slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-pubsub-profile-for-groups-00 Palombini summarized the updates in -02 of draft-palombini-ace-coap-pubsub-profile. Q: (Eve Mayler): Per slide 8, you've defined a standardized interface for KDC which is a function of the AS that is OATH protected. That makes it an RS? A (Palombini): It does not do authentication. A (Mayler): To clarify, is my understanding right? I've written a spec that has a very similar design pattern. A: (Palombini): Yes. Q (Palombini) to WG: Do you still support this work? [no feedback] Joining of OSCOAP multicast groups in ACE ========================================= draft: draft-tiloca-ace-oscoap-joining presenter: Marco Tiloca slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-joining-oscore-groups-using-ace-01 Tiloca summarized the changes made from -02 to 03 of the draft. This revision Q: (Tiloca): Is this draft ready for WG adoptions. A: (Selander): There is interest to create protocols for simple devices. This draft could solve some of these problems. A: (van der Stok): I support this document. Key exchange for OSCORE ======================= presenter: G?ran Selander slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-key-exchange-w-oscore-00 Selander contrasted the options to a key exchange protocol with OSCORE -- Option A: reuse transport layer security at application layer; or Option B: a compact key exchange protocol using CBOR and COSE. Q: (Selander): Per Slide 6, .. A: (Michael Richardson): The result of not having a key exchange will be reduced security. We deployed a variety of protocols without security protocols before. It is unfair to say that there has been no security analysis. A: (Selander): Yes, but there haven't been papers. A: (Richardson): Bugs will be found after reviews are done. Thanks for slide 5. Did you run the numbers on raw public keys? What was the overhead? How can raw PSK be less than the public keys? What keys? A: (Schaad): 256 ED25519 Q: (Malisia Vucinic(?)): From the experience of 6TiSCH, I support Richardson's comments. TLS isn't ready on our timeline. Comment: (Tschofenig): You are asking us to re-implement TLS on CBOR/COSE. The reason TLS looks as it does, the standards process added various features/functionality. That functionality then needs to be maintained by implementers. These changes add more work. A: (Bormann): We are implementing these features in open-source projects. Time to market is an important differentiator of companies. A: (Tschofenig): I appreciate your research implementation. You are down-playing the investment required. It takes us a long time to right solid implementations. We want to reuse code. Shaving off a few bytes and adding others requires reuse that we're not seeing demand for in our customers. A: (Vucinic): The companies we are working with are interested. A: (Bormann): I agreed that we need implementations that are production quality. Counting open source implementation isn't enough. TLS doesn't currently do what we need it to do. We need an adapter. A: (Tschofenig): The adapter is a key extractor. It has been used. I'm still waiting for deployment of OSCORE. Comment: (Kathleen Moriarty): Thanks for your work measuring the byte sizes. The IoT market is large enough for different architectures. I'd like to see it continue. There is sufficient time to still perform security analysis. Scope of ACE Authorization Work =============================== presenter: G?ran Selander slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-scope-of-authorization-work-00 Selander framed discussion on the scoping and defining around the next steps of the authorization work across all of the WG and individual drafts given the ACE framework. Comment: (Seitz): As to the ACE mode of operations, let's not limit ourselves to just what we have adopted as of now. Q: (Schaad): How soon is pub-sub going to be done in CORE? A: (Bermann): There is confusion about terms. The pub-sub profiles are a bit different from the way they are being described in ACE. Interest is picking up -- perhaps a half year to address issues. A: (Schaad): What about OSCORE draft? That's still an individual draft? A: (Bermann): It has been adopted. Q: (Kaduk): Any opinions -- we have open mic time. (Bermann): When we started, we had an idea of the problems to solve. We agreed OATH would be a starting point. I would like to complete that work and then move on to new work. We should do new work too on authorization/authentication in IoT. More discussion is required. We are not done as a WG. (Tschofenig): Why are people already talking about closing down the WG. The drafts aren't finished. I concur that we should reassess what else has happened since we tried to understand the problems. For example, in the home IoT there hasn't emerged a big interest in standardized solutions. The industry IoT has shown interest. We should double-check which original ACE use cases are still applicable and let that guide the future work. Wrap Up ======= Q: (Kaduk): Who has read the EDHOC draft? [about 15 people] Q: (Kaduk) Are you interested in adopting the EDHOC document? [Moderate strength hum to support adoption] Q: (Kaduk) Are there specific technical objections to EDHOC (not business ones)? A: (Tschofenig): I would be interested to see the detailed numbers posted to the list -- the protocols have different features. Message size is not the only feature to measure for performance. A: (Kaduk): Yes, the numbers will be posted and we should discuss on the list. Open Mic ======== Comment: (Tschofenig): I will post an article from Networking Magazine about problems we are encountering in the IoT space. This creates a conclusion by the public that the IETF work is not done and not ready. Comment: (Moriarty): It doesn't appear that any technical objections were voiced to EDHOC. To confirm, it is going to the list to discussion? A: (Kaduk): Yes (on both). Comment: (Selander): This isn't about replacing TLS -- double stacks.