Skip to main content

Minutes for ACE at IETF-93
minutes-93-ace-1

Meeting Minutes Authentication and Authorization for Constrained Environments (ace) WG
Date and time 2015-07-22 07:00
Title Minutes for ACE at IETF-93
State Active
Other versions plain text
Last updated 2015-07-28

minutes-93-ace-1
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.