ACE WG Meeting Minutes IETF 93 - Prague Wednesday 22 July 2015, 9:00 - 11:30 CDT Chairs: Kepeng Li, Hannes Tschofenig 0900 Kepeng Goals Activities Related: COSE, T2T RG Summaries: we have around 100 people for T2T RG meeting. ----------------------------------------------------------------------------------------------------- 0905 * Use Cases (Ludwig Seitz, 10 min) - http://datatracker.ietf.org/doc/draft-ietf-ace-usecases/ One of the first drafts on the WG, adopted two meetings ago. Now we are just updating when reviews came (some delay by holidays) I will give just a quick overview (you can talk to me if need more info) (slide 2)Iot UseCases GOALS: not to collect all possibe UC. Try to be solution neutral/dont go into tech detail. we can lose generality. When we focus on general, the better (slide 4) Reviews: 5 reviews. I feel happy with these number of reviews. There is not much more to say bout UC . Unless you have qquestions Kathleen: I think the UC doc is ok, wee need to integrate these comments, we have to be quick. Please do your reviews, so we can do a WG Last call. No more questions. --------------------------------------------------- 0910 * Public Safety Use Case (Akbar Rahman, 10 min) - http://datatracker.ietf.org/doc/draft-rahman-ace-public-safety-use-case/ After I reviewed the doc, I found that there is at least one UC that needs to be reviewed. Im giving you input and you consider my comments just as that. *Fire Department UC description.. We NEED Non Repudation. For me its a main problem we need to take care of. * Authorization Problem summary. (Requirements) If I look at these Req, starting at REq 6 for me its new Requirements that have not been adressed before. please we have to consider them. Ludwig: Thank you for contributing, is useful. Maybe we can expand We have another draft on another WG (didnt get the name). Non repudation is a term that the meaning is on discussion. We should get clarification about what it means. Katheleen: Id like to see howe we are using "non repudation" term in the other drafs . Hannes: fo me in this document the use of the term is clear. Kathleen: we should agree on a definition and put it on the main draft. Ludwig: we decided in ACE not to do adithing (talking about R8) I want to be sure is out of scope. C Bormann: This is very popular UC. I think there is a lot behind this UC. We should not try to cover all of it here. We can do on the T2T RGroup.. I agree with the seven Req Though ??: I think you have another requirement. There is another Requirement: you have to adapt to the constraints of the fire deparment (whatever system they already have) ???: for me R2 is an oversimplification. On the UK the roles are defined. This is not dynamic. Whoever shows up with the appropiate .... about R5(orR6?). for me its not a security Issue (integrity). ??: Please dont talk about NON Repudation. Is very confusing. we gave up on that (talking about other wg). The implications are huge , its abig legal issue. We dont want to adress it at out level. Kathleen: I agree. Its anapropiately used in the "actors draft", even there is being misused. Whe should focus on Authorization and Authentication. ????: We are trying to asses too much. Lets focus. Carsten: We should write down that the entiry is ... Robin: Non Repudations. Has very strong legal implications. Hannes: please give us feedback. about non-repudation. clarification on integrity of the data. whe should include this on the UC document: 12 hands Ok, 2 hand no. Conclusion: We will include it. ----------------------------------------------------------------- * Actors (Stefanie Gerdes, 10 min) - Carsten B. Presents - http://datatracker.ietf.org/doc/draft-gerdes-ace-actors/ * Architecture Drats are merged. In the last meeting we agreed on that. We need more reviews (only jim reviewed). so we can go to the adoption call. Kepeng: who read the new version of the doc? Around 10 people read. Hands around 18 to adopt. No one against. We will ADOPT the document. Who wants to do reviews? 5-7 hands (taking tha names of them). Hannes: -------------------------------------------------------------------------------------------------- 0933 * Authorization for Constrained RESTful Environments (ACRE) (Ludwig Seitz, 20 mins) - https://datatracker.ietf.org/doc/draft-seitz-ace-core-authz/ * This drafs covers additional UCs. * Flows slide * Auth Schemes slide (push, pull , client-pull). Client-pull: we came up with it ourselves. I hope its useful. RS does not do auth, it replies with a protected resource (encripted signed). the Client has to ask for the AuthServer to access the unencripted info. The RS can be really light-this offloads a lot. MIC Shegen?(sics swedish ict): We can ask to the RS without any authentication? (answer is yes: because is so cheap to reply). But then this is open to anyone? We need some sort of authentication. Goran: The client-pull is based on example B (broker). The idea is that you offload the RS. "Shegen"?: I do not agree that we dont have any intermediate node (that provides auth). If anyone can contact my RS, I think this model does not work on iot. Malisa Vucinic?: why are you authenticating someone? because you want to gave him access to the resources. on the RS you don't care because it is encrypted. In terms of energy, it costs the same (encrypted or unencrypted) dave robin: I like it. DoS comment. If someone does not have credentials you silently ignore it. question: you do encryption over and over again? (answer: no, on RS we encrypt once then we send that -until next time the real value changes, we reencrypt-) Jabber room: of course, anyone can do a DOS attack with (D)TLS init messages, and also can continuously try the "authorization" . (robin wilson: symmetric instead of PKI) /.../ Robert craig: Does it make sense to give a locked box? I think yes, its cheap. Alex Pelov: I really like this one. there is some similar system on some credit card system. Malisa Vucinic: Energy aware. sending 1 bit on radio cost the same as encrypting 1000 bytes (hardware), in energy . evaluate energy. Thomas Watteyne: I like it. Its like a normal RS ? -no additional cost- (answere: there is some overhead for encryption -headers-) Goran Selander: if you have an intermediate node you need to publish once, so it does not matter if its a big locked box or small. information centric applications require something like this (encrypted once, used multiple times). suggests another document that may be useful here. 0957: Presentation continues -RESTFUL Authorization Resources (slide): asks for some way of discovering auth resources. .well-known can be used? MIC: olaff bergman: yes, with .well-known/core, we can include an auth resource. - ACRE Design Principles. Carsten B: I think there are two building blocks here. That they can use REST, we dont have to reinvent. We only have to define resources, attributes and things like that. Rob craig (?): is it really restful? are you creating resources with POST? answer: you are creating authorization information. (he explains why we use POST and not GET.) If you use GET it gets complex the especiffication of what you want to get gets big and if you put on headers you cannot use blockwise.. POST you can use blockwise) Sandeep K.: how do you plan on doing replay protection? ( answer: sequence numbers. sandeep: client does not know seq. ludwig: we need a reliable clock if we dont this is a problem I agree) Goran: /check answer/ how a client will know if its a recent representation. --------------------------------------------------------------------- 1005 * DCAF Examples (Stefanie Gerdes, 20 min) Presenter Olaff B. - http://datatracker.ietf.org/doc/draft-gerdes-ace-dcaf-authorize/ - http://www.ietf.org/id/draft-gerdes-ace-dcaf-examples-00.txt - Review of DCAF. Ticket (access token) - PSK Derivation. - DTLS, authroized requests (CoAP traffic) - Flexibility (99% of the UC) 1012 Second presentation (dcaf examples) - Use Open ID connect with OAUth. - Flow 1. Authentication with openID connect. - Flow 2: Autorization with OAuth/DCAF. - Summary (Use common protocol on the less contrained level that interoperate with DCAF. DCAF for the constrained part) One important thing is that the Authorization is assumed on the DTLS cannel. - Next Steps: more interction examples (contribute please) - Standardize DCAF as one of the ACE building blocks. Q&A Goran: what does it means stanardize? DCAF is one thing, and OAUTh is other. Which you are you refering to? Olaff: standardize DCAF. Goran:client-pull, some models are not issued here. Hannes: discussion at the end of the meeting. ? ("Tonia"): what is constrined and what is not? Olaff: the clasification is on RFC 7228 Class 0, Class 1 , we assume these definitions. my question is, when somebody tries to implement your protocol, he will need some guidance (which is constrained or not?) we need some numbers. Olaff: for instance Class 1 you can do Symmetric cryptography. Malisa Vucinic: We obvioulsy have different classes. The WG keeps talking about memory - memory is not a problem. The big problem is ENERGY, radio communication. We should work on reducing radio exchanges. On this WG we should focus on that as well (energy consuption, minimize messages, when we can wake up -RDC-, discussion about timers) Olaff: yes energy is a problem. We decided to use DTLS. Malisa Vucinic: you said you addres 99%. None of the existing WSN deployments with application level gateways are addressed. Hannes: its an important point energy, we should address. ???2: I would not call ?? a Class 1 device. Alex Pelov: Interesting, maybe put at the begining the use cases. 1029 How may people read DCAF drafs? around 20 ----------------------------------------------------------------- 1030 * Multicast Security (Sandeep S. Kumar, 20 min) - https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/ - a typical professional lighting system. (groups, can be overlapping) - system level requirements. We need multicast, we need to be fast. - group concept. application group, multicas group, security group. (three diferent concepts) - multicast vs application vs security example. things can get complicated in terms of grouping. - typical lighting systems workflow. istalation. commisioning (problem backend not yet installed). - security design. two step process. 1st: commisioning (acces tokens) -security design. 2step ; operational access token for Resource. - access tokens. bearer token, or proof-of-posession token, we need to work out the details. -open issues-work in progress: revocations, sleepy nodes.... 1038 Q&A John "grol": I really liked the draft. specially the case of instalation. My questions about group comm, multicast will be addressed on dice? Hannes: DICE will be closing soon. Multicast will not be addressed. John: youre gonna get to this point eventualy multicast. CBornmann: what we tried in DICE ... we may try next is to use the COSE structure to adress multicast. Thaat maybe a good base to have a base for solving multicast. My question is about 'step 2') why you send the token. how you know the reveiver gets the messages. Sandeep: yes we should take care of lost messages. Hannes: Polling, what do you think in terms of scoping. today we have UC , lighting as one of the UC. I dont think the charter says that we have to work on multicast. maybe this can be in another group. who is in favour of covering multicas on this WG? around 20. ???: there are other ways of group communication other than multicast. other possible solutions. robert craig: should we include the UC? yes.. should we include solutions? .. what was the question? Hannes: on the UC doc is already. I repeat the question. Should we be working on distribution of group communication meys on this WG? yes 15 Objections? none. 1046 ARM: whe should include .... // Hannes: not now // ------------------------------------------ 1045 * Simplified Key Exchange (Thomas Hardjono, 20 min) - https://www.ietf.org/id/draft-hardjono-ace-fluffy-01.txt Thomas is not opresent on the room. we don have the slides. Hannes: pity. these solution addressed in some way key distribution. ---------------------------------------------------------------------------------------------- 1047 * OAuth and UMA (Hannes Tschofenig, 20 min) S. Erdman presenter. - https://www.ietf.org/id/draft-maler-ace-oauth-uma-00.txt - Motivation. Look at others standars, how can we bring this to IoT. - Mapping of Use case to existing IAM technologies. Mic ?: Instrospection assumes connectivity. doest not work withouth, this is a problem. goran: introspection requires botht to connect or can be an ordinary-pull? (answer: no, cannot be used) hannes: you need both. (cotinues presentation) - Door lock use case. - authentication and authorization to the door lock use case -door lock access. we found a lot of intereseting use cases. T2TRG talked about a cookbok for scenarions. great, I have good ideas. - Abstract Boostrap scenario. needs to be done. step1(discovery, as uri, provisioning keys) - abstract boostrap scenario; step 2, we register to auth server. - abstract access flows. diferent access scenarios (can be mixed) -how do we do today in the real work? bootstraping resource resistration. - both online. everithing works. - both offline . these is deployed and works. how can we adop these tech into the constrained world?: -bootstrapping resource registration (coap) -both online, offline (pointer to drafts) -document roadmap: scope, bootstrap, access. (some are ddone, some are coming, some needs to be done) there is no new ideas, no new concpts, is just mapping and making them work. -next steps. 1102 Q&A "mohic" ericsson: slide abstract bootstrap flows step 1. I think is easier to say bootstrap is out of scope, but we should give some pointers. Hannes: out of scope here is because of the way we defined the charter. "mohic": Authentication and authorization to the door lock. how is this done? Erdman: this is a leap of fait. Hannes: is a common problem, in almost all documents is assumed at some time there is some out of band channel. "mohic": fine for me. ?? ericsson: whe your phone is out of battery what do to do? ericerdman: yes big problem. you need backups, rfid, a real key. max?? cisco: we are working on bootstraping problems ANIMA WG, we have documents,. maybe you can use them. hannes: the problem with is that the bootstraping concept is that broad maybe is not on the same meaning. maxx cisco: one document ends when the bootstraping is done. hannes: some docs Ive read assume you had a psk or manufactures, its an egg chicken.. how do you it there on the first place? maxx; ok.. yes we are working all on the same problem 1110 ------------------------------------------------------------------------------------------------------- 1110 * Privacy-Enhanced Tokens (Jorge Cuellar, 10 min) - https://www.ietf.org/id/draft-cuellar-ace-pat-priv-enhanced-authz-tokens-00.txt - our focus: constrained devices. how often you whant to change your battery? makes a difference. - Actors (as in DCAF), is similar. -Possible conflicting Goals. Privacy is one of the main concerns. Energy Consuption, is the main constraint here. We need measurements. perhaps we can have some kind of measurements document. 1116 mic ludwig seitz: I loked for a long time for the same (document). Im not optimisting we aree going to find one or agree. Two papers, contradictory, transmission is more expensive than public crypto the other says the other whay round. ??: I have one document. we are planning on submitting to LWIG WG. maybe you can use it olaf bergman: what you mean when you talk about code size? answer is the ram, I dont robin wilton: privacy bullets: non linkability of identities of comm parnetrs. do you mean A. the client identity should not be liked in between two access to the same rersouce. B. ?? /listen audio/.. 1119 presentation continues - one solution possibly does not fit all. - a possible way forward. finished 1122 ------------------------------------------------- * Wrap-up (Chairs, 5 min) 1123: MIC Goran selander: we have one categury of questions; group comm, multicast? other questions; is this draft going to be part of a building block? Hannes: we are talking about Hannes: we want to have a feedback of where are we going to? If you have preserence. Goran: if there is apreference for a particular draft, and there are variants. what we do? hannes: we ask what is there. Kathleen: we should do a poll soon. to start with solution. close with the actros. we may combine drafts. but we have to have an idea of where are we goind on. Hannes: we will do on the mailing list. Kepeng: we want to ask wich solution .. Hannes: you raise your hand if you are confortable with the solution, you can raise your hand multiple hand Hands: ACRE: 18 hands DCAF: 15 OAUTH/UMA: 20 Privacy tokens: 13 Kathleen: is not a clear consensus.. robert vraig: is not ACRE implied on DCAF?. answer now ??: for the UC when the push model is the solution, I dont have issues with DCAF, I dont think its 99 percent of the . Goran: relationship in ACRE and DCAF: Hannes: we should do on the list symmetric vs assymetric, etc ??: I will push DCAF more than the OAuth. I will like to bind them together more tightly. I really like looking in terms of what model offers what. ?? ericsson: We also have sandeep: I like multiple solutions, because each of thems solves differents problems. I prefer diferent models. I want different models. Jorge: I would like to merge with DCAF. hannes: your solution is very generica can be merged with anything. Jorges: yest but is very close to DCAF. I think its relatively easy to merge. Chadley: Building bliocks, I agree with Carsten Borman. Kathleen; plan interim meeting. So we can move UC and Actors forward. 1135 thank you.