Minutes interim-2020-core-07: Wed 16:00
minutes-interim-2020-core-07-202006241600-00

# CoRE Virtual interim - 24-06-2020 - 14:00 UTC

Chairs:

* Marco Tiloca, RISE
* Jaime Jiménez, Ericsson

## Remote instructions

material: https://datatracker.ietf.org/meeting/interim-2020-core-07/session/core
webex: https://ietf.webex.com/ietf/j.php?MTID=m08cd303bf882c3eeebacf6d60d7b202e
jabber: core@jabber.ietf.org
codimd: https://codimd.ietf.org/z_MRgsGdTeechGxvL56MQw

Minute takers: Francesca, Marco and Jaime (helping)
Jabber scribes: Jaime

## Participants

1. Marco Tiloca, RISE
2. Jaime Jiménez, Ericsson
3. Jim Schaad, August Cellars
4. Jonathan Beri, [Golioth](https://golioth.io) (startup)
5. Francesca Palombini, Ericsson
6. Peter Yee, AKAYLA
7. Rikard Höglund, RISE
8. Thomas Fossati, arm
9. Klaus Hartke, Ericsson
10. Carsten Bormann, TZI
11. Christian Amsüss
12. David Navarro

*[MT]: Marco Tiloca
*[JJ]: Jaime Jiménez
*[JS]: Jim Schaad
*[FP]: Francesca Palombini
*[CB]: Carsten Bormann
*[CA]: Christian Amsüss
*[KH]: Klaus Hartke
*[RH]: Rikard Höglund
*[TF]: Thomas Fossati
*[DN]: David Navarro

## Agenda

### Note Well

Remember that the [note well](https://datatracker.ietf.org/submit/note-well/)
applies, for [IPR](https://tools.ietf.org/html/bcp79) but also for [WG
processes](https://tools.ietf.org/html/bcp25) and [code of
conduct](https://tools.ietf.org/html/bcp54). Try to be nice.

### CoRE Updates

- draft-ietf-core-senml-etch-07 --> [RFC-to-be
8790](https://www.rfc-editor.org/auth48/rfc8790)
    - AUTH48 done
- draft-ietf-core-senml-more-units-06 --> [RFC-to-be
8798](https://www.rfc-editor.org/auth48/rfc8798)
    - AD
- draft-ietf-core-oscore-groupcomm-09 --> WGLC coming soon.
    - no urgency but good to have WGLC comments by IETF108
- https://arkko.com/ietf/core/draft-ietf-core-dev-urn-from--04.diff.html -->
Update from WGLC

### Updates to the Resource Directory document addressing latest comments

https://core-wg.github.io/resource-directory/draft-ietf-core-resource-directory.html#name-changelog

CA: AD review and other feedback -> update in github (see
[changelog](https://core-wg.github.io/resource-directory/draft-ietf-core-resource-directory.html#name-changelog)
)

https://core-wg.github.io/resource-directory/less-security/draft-ietf-core-resource-directory.html#name-security-policies

CA: Sec cons: we didn't have much initially, then with feedback we added a lot.
We should rather have a more general approach. Drafted it in the PR.

CA: 2-3 more issues pending:

* https://github.com/core-wg/resource-directory/issues/234
CB: the discussion comes about twice a year. Yes, we want to have simple
registration CA: would like to have feedback on if this (see issue) is the
direction the WG want to go to.

CA: finish the PR, send a mail to the mailing list, submit new version, claims
it adresses review comments

* Related documents
   - https://tools.ietf.org/html/draft-ietf-core-resource-directory

---

### Resource Directory and Authorization

* Related documents
   - https://tools.ietf.org/html/draft-ietf-core-resource-directory
   - https://tools.ietf.org/html/draft-bormann-core-ace-aif
   - https://tools.ietf.org/html/draft-ietf-ace-oauth-authz
   -
   https://tools.ietf.org/html/draft-amsuess-core-resource-directory-extensions

KH: no updates since february meeting.

JJ: Please short summary and link (anyone).

KH: RD said "if you need authorization please use Ace". How to do that in
practice?

JJ: Minutes?

CA: Can help a bit. Registrant and look up client are Ace clients, RD is RS.
There is 2 ways the registration can happen: either the registrant already
knows what token to get in order to register, but most likely the registrant
will try to do the registration and get an error message that redirects it to
the AS that will give it credentials.

JS: authorization only for registration or also for lookup?

CA: In Lookup it can work in the same way. First time it would get a 4.01, and
then it can go to the auth server.

CB: RD is agnostic to the onboarding process. Onboarding has to come from 
somewhere else. RD is just an application that is useful in that process.

CA: what does onboarding mean in particular in this situation?

CB: That's the interesting question. We are trying to provide one component
that can be use for a specific process.

MT: Do you think AIF would help in the registration case?

CB: not sure we need another case. This should be described by AIF. Who can
actually give that authorization in a way that RD listens to it? But outside of
scope of the RD doc.

CA: might need to include query parameters in the AIF. Agree that AIF should
cover it.

JS: need to think about dynamic points.

CA: registration resources. The ability to use scope /register?ep=foo implies
that one can also do the registration on /register/ep/foo.

JJ: LWM2M there is no ...

JS: what sort of detail? I can set up an AS and a RD that could do this. Is
this what you are looking for?

JJ: LWM2M - when an endpoint registers on a LWM2M server, there is no
registration needed, because it's a trusted component. There is no lookup
function from the IoT side.

CA: The RD would be preconfigured with the set of keys/name matches and it can
use the key to decide which registrations are allowed.

TF: yes.

DN: LWM2M server is preprovisioned with the credentials of the endpoint it
communicates with.

CA: wouldn't put concrete text about Ace in the doc. Details depend on the
application

CB: RD is agnostic. If you want to have something like SNMPv3 you need to have
security.

JJ: scope of this interim was not to make more changes to RD draft. This
interim was about how to simplify Ace for RD (continue February discussion)

CB: How to handle dynamic resources? (not discussed in Ace)

CA: Every statement of a resource is transitive over location links from there.

CB: Yes, still applications can do it different but it is a great way to do it
as a default authorization for RD.

JS: Other issue to be discussed is what the RD is to do when authorization
expires.  Implies that tokens for authoriation might not be short term

CA: No further updates can come up after the end of the lifetime and the
resource goes away.

CB: Lifetime of a dyn created resource cannot be longer than the lifetime of
the authorization credential.

CA: If the client were to request a longer lifetime it would be 4.01 rejected
and be redirected.

MT: No margin btw token expiration and the deletion of the resource.

CB: Everything that the client is doing based on the authorization would have
to inherit the time limit.

CA: ... and not to include larger lifetimes cause it'd be rejected.

CB: ...

CA: CoAP Problem could help on this.

MT: To be added to the draft?

CB: Wouldn't like to limit it to ACE

JJ/MT: Sure, no intention to be prescriptive.

JS: in LWM2M we are saying that the lifetime of the key is infinite, right?

JJ: lifetime is a parameter of the registration.

DN: what key are we talking about?

JS: whatever key you use for authentication. Let's say the TLS key.

CB: How do keys expire?

DN: there is no specific mechanism on handling key expiration on the endpoint

CB: do participants know when the key is going to expire?

DN: The endpoint does not know what the lifetime is.  It will attempt to
contact the server and the server will return an auth error when the key
expires.  The end point then contacts the bootstrap server to get a new key.

CB: is there going to be a draft about this?

JJ: if we need to, somebody could try. Now not so sure.

CA: text that describes an example how a RD with AS etc could play together. I
could fit it for now in RD extensions.

CB: another option would be to write something in the AIF doc.

KH: In the February meeting we discussed how to combine IETF components to
identify potential gaps. Now it seems we have a way forward also considering
possible additions to AIF.

JS: Should we spend 1 hour or so anytime soon?

KH: It would help a workflow example, including discovery and then
authorization request and enforcement, etc., putting all components together.

JS: I could never convince anyone it was important. If one gets an error from
the RS, this points at the right AS to go to, but not the scope to ask for, as
the client should just be totally agnostic of "what" exactly ask for.

KH: I guess things might not be entirely clear when we consider Commissioning
Tools, rather than devices registering themselves. E.g., how does the CT get
the authorization to act on behalf of the device?

CA: From the Authorization Server as well. Depending on the level of details it
is aware about, it can ask for more or less fine-grained scopes.

KH: So in theory all components are here, but it would be nice to have an
example showing that the components can actually be combined in practice as
envisioned.

CA: Anyone having both an RD and ACE stuffs implemented?

JS: You can use your RD and my ACE.

CA: I can use your AS but I would have to adapt my RD to be RS.

JS: Yes.

JJ: In LwM2M we have implementations but this exercise is only for registration
so not so useful. Wondering if others can be interested.

CA: a 4.01 error can tell to go to the Bootstrap Server as a redirection to get
new/updated keys.

JJ: How does OCF do?

TF: No idea.

CA: Can one device have in LwM2M something like, if you have problems accepting
me, check with this Bootstrap Server?

DN: The interaction between Bootstrap Server and LwM2M server is not defined in
the specification. What we call LwM2M Server is actually both RD and CoAP
client. So the BS configures a device upon bootstrapping, making it able to
continue talking to the LwM2M server, which performs CoAP operations on the
devices.

CA: So when the device reaches the LwM2M server, the BS has everything needed
about the device to possibly share.

MT: It's still good to have informational guidance somewhere. The RD extension
document?

CA: Or actually the AIF document (appendix) explaining how that can work for
this.

JS: And at some point we may want to have that as an informational document
from ACE anyway.

CA: What about LwM2M Proxying?

JJ: As far as we know, there is no proxying in LwM2M. All endpoints are both
client and server.

CA: Not thinking of direct communication. It seems there is no current way for
a non-IoT side to communicate with an IoT side. If that becomes interesting to
do, entities like proxy would also become interesting.

DN: we are finishing LwM2M 1.2, then we start a requirement phase in September.
It has not come up yet a possible work/interest on a device accessing resources
at another devices, given authorization/guidance from the LwM2M server.

CA: You will need to have a base address.

DN: The RD may be a main provider.

JJ: Yesterday we had a discussion about proxies and the Dynlink document also
thinking of LwM2M. This discussion will continue with more follow-up.