ACE WG Meeting IETF 100 - Singapore The ACE WG met Tuesday morning. There were two new chairs from the last meeting with Ben Kaduk and Jim Schaad replacing Hannes Tschofenig and Kepeng Li. Our thanks go out to the past chairs for the work they have done to get the WG to this point. Mike Jones gave a presentation on draft-ietf-ace-cbor-webtoken. The document is in WGLC which will end on 29 Nov 2017. There have been a couple of issues that have been found so far in the LC which will need to be addressed, it is expected that a revised document should be done soon. Issues raised during the discussion were: • JWT intentionally used strings for fields since they were supposed to be human readable. It would make sense to look for smaller formats for CWTs. (Hannes) • Should scope be defined in this document as the OAuth Profile document uses it? (Hannes) • Not defined in JWT and the intention was to make these documents as parallel as possible. • What should be happening as documents like the framework defines new claims? (Ludwig Seitz) • Register the claims, include a numeric claim number if desired, in the IANA registry. Mike then gave a presentation on draft-ace-cwt-proof-of-possession. Still some outstanding issues that need to be addressed from the previous version. He believes that the technical aspects of the document are stable, mostly editorial type issues left. No issues were raised during discussions. Ludwig Seitz gave a presentation on draft-ietf-ace-oauth-authz. There is a desire to try and do an interop event on this document no later than the London Hackathon. Issues raised during discussion were: • It seems that the framework is mandating CBOR and CoAP formats. (Hannes) • Ludwig believes that these are not mandated, but will review the document again to ensure this is true. • The client token concept is new in this document and is not in base OAuth. It feels like there has not been sufficient thought put into this. Perhaps it should be moved to a different document. (Hannes) • This needs to have some discussion on the mailing list and a decision made. • There were people who both supported removal and keeping client tokens. • There was worry about possibly needing to support multiple forms of tokens. • Should there be the possibility of sending multiple profiles from the AS to the client so it can choose which of the supported profiles to use? (Francesca Palombini) • Need to have a better use case before being considered. The AS knows the supported profiles both CS and R and thus can always send back a usable one. Francesca Palombini gave a presentation on draft-seitz-ace-oscoap-profile. The title of the document has been changed to reflect the change of OSCOAP to OSCORE. The document finished an adoption call and the chairs have called consensus to adopt the document. No issues were raised in discussions. Paul (?) and Dave Thaler volunteered to review the document. Göran Selander gave a presentation on draft-ietf-ace-dtls-authorize. The following individuals volunteered to review: Francesca. Issues discussed were: • Two methods to send authorization to the server. Authz-info resource and psk_identity both documented. • Authz-info mandatory, but permission may not be granted (Carsten Borman) • Does client have to implement both (Hannes) • Authz-info is required for doing re-authorization, cannot be done by psk_identity unless you reconnect the DTLS session. • Should PSK and RPK be two different profiles or aspects of the same profile? • Problem is probably more of an issue for different transports (Hannes) • AS knows the capabilities of the client and resource server, it can always return the right one. • How does a server identify a token in the psk-identity slot? Current proposal is try different options. • Ericsson might have an IPR issue on this document. Should be announced later in the week. Marco Tiloca gave a presentation on draft-aragon-ace-ipsec-profile. Issues discussed were: • The access token request can be sent without a proof-of-possession in the request since it uses IKE. This can be an unknown key share attack. Should be either in the security considerations or dealt with. (Dan Harkins) Marco Tiloca then gave a presentation on draft-tiloca-ace-oscoap-joining. The following people volunteered to review: Carsten, Eliot Lear, Göran, Peter. Issues discussed were: • This work closely mirrors the pub-sub document. It would be good to try and consolidate the work. (Carsten) • Would like to get the document adopted by the WG. • Chairs will need to review the status of this document and the pub-sub document and make some decisions. Document is dependent on a the multicast OSCORE draft in CORE. Peter van der Stok gave a presentation on draft-vanderstok-ace-coap-est. The following people volunteered to do reviews: Eliot Lear, Brian Weis, Dan Harkin, Max Pritikin. The chairs intend to do an adoption call on the document in December. Issues raised during the discussion were: • Server-side key generation, what is the value and should this be here or separate. (Hannes) • What level of BRSKI should be in this document. The chairs then led a discussion on the issues surrounding doing a group communication protocol with particular emphasis on the really lightweight protocol that some believe is needed for use with a lighting protocol. This is an attempt to provide the issues discussed, but no attempt is made to either give attribution for the discussions or to maintain chronology. • It was clear from the discussion that there are going to be many different levels of security and latency that exist in the scenario. In some cases (nuclear power plants) it is far more important that high security is maintained while others (office lighting) have significantly less problems. Even within a single setup there may be some actions (fire department door opener) that are going to have different security requirements. • One different way to layout the problem space might be to divide it into those where all of the devices have a homogeneous vs heterogeneous levels of privilege. In the first case, all elements in the security group can cause any other element to execute a command. In the latter case the set of elements that can issues commands is a designated sub-set of the entire group. This distinction makes a big difference if one is looking at the security model from an escalation of privilege problem. Can a node gain the ability to do something that it should not be able to do? • Discussions of what latency means as a security concept is fraught with problems. Some cases, such as room lighting have specific latency issues that need to be considered, but are not necessarily security specific. In other cases, such as phones, latency can be faked by generating feedback to a user independent of any actual completed event. (I.e. the phone on the other side is reached.) Latency is more of a problem when dealing with people rather than machines as they may have incorrect assumptions about how long things need to take. • Worries exist over the problem of solution creep. If a solid proposal is adopted for dealing with a case like home lighting, what types of restrictions can be put into place to prevent this from also drifting into cases where it is either less or not appropriate. The proposed solution would have both a key distribution protocol and a set of requirements when authentication are required, but how easy is it to ignore these and then claim to conform to a security protocol. The chairs then attempted to conduct a set of hums to get a sense of the room. • Are low security systems a class that should be solved by the IETF? Not all devices share the same privilege, compromise allows for an elevation of privilege o No strong consensus shown. • Reformulate as: In systems where a breach of security is deemed to have minimal impact by the owner of the system. o No consensus, but a stronger lean towards ‘No’ • All devices share the same privileges. Compromise of a device does not allow for additional privileges to be given. o Strong consensus that this is work the group would like to see done.