OCF OSCORE virtual meeting

Repository: https://github.com/t2trg/2020-03-ocf-oscore
18.3.2020

Note takers: Jaime Jiménez (day 1), Christian Amsüss (day 2), et al

Attendees

Ari Keränen (AK)
Carsten Bormann (CB)
Christian Amsüss (CA)
Francesca Palombini (FP)
Göran Selander (GS)
Jaime Jiménez (JJ)
Jim Schaad (JS)
John Mattsson
Klaus Hartke
Marco Tiloca (MT)
Olaf Bergmann
Oleksandr Andrieiev (OA)
Peter van der Stok
Phil Hawkes (PH)
Rikard Hoglund (RH)
Thomas Fossati
Vincent Audebert
Wouter van der Beek (WB)

Continuation meeting: AK, CB, PH, Oleksandr, CA, FP, GS, Klaus, MT, Olaf, Peter, Rikard, Wouter

Draft agenda

• CoRE / ACE / LAKE overview? (Marco)
• OCF and OSCORE (Phil)
  • Explain how OCF plans to use OSCORE for End to End Security of Unicast Messages.
  • Explain how OCF expects to use ACE, EDHOC
  • OCF interim plan: "Directly Provisioned" OSCORE Security Contexts

Meeting Minutes

AK: Introduction. T2TRG and CoRE topicwise, T2TRG is a facilitator. Today's topic is OSCORE. Few question's coming from OCF (Phil) and short presentation on OSCORE (Marco).

MT: Presenting "Overview of CoRE, ACE and LAKE". (material on the slides)
LAKE on Key establishment. ACE focus on key management and access control…

PH: Presenting "OSCORE: OCF Status and Comments". (material on the slides)

Presentation on how they are planning to incorporate OSCORE on OCF.
Focus on E2E sec of unicast messages, no group oscore atm. No Auth server functionality in OCF atm. Want to use ACE and EDHOC.
Q: What's the expected timeline for the oscore profile for ACE and EDHOC?
GS and FP: Close to publication in ACE, IESG review needed, at least a month. very stable.
JS: As ACE chair, waiting for DTLS profile to be finished with AD review and then entire set of documents will be shipped.
FP: OSCORE profiles does not depend on that.
GS: EDHOC is completing requirements phase. Adoption call for solution at the end of march. Hope for adoption then. It is already compliant with requirements. Target is about 1 year. LAKE milestone is for WG publication in Autumn.
FP: ACE OSCORE is in ACE WG, EDHOC is in LAKE (a focused short-term group).
PH: On the group oscore documents…
FP: Some of the other documents referred are not needed if you are not planning to use groups.

PH: Waiting for ACE, plan by OCF is to use the "Directly Provisioned" OSCORE Security Contexts. Similar approach as LwM2M.
GS: LwM2M has a Bootstrap Server that is used to provision the security context.
PH: We will do it in a similar fashion.
PH: OSCORE for us refers to RFC 8613
PH: Showing slide 4. Proxies to have TLS/DTLS connections in between and OSCORE on top E2E (orig client to target server). Server will identify that connection, roles will be assigned based on it. Once that is in place, existing policy engines can be applied straight in. If no E2E security it will use the proxy as identifier (?).

PH: Showing slide 5. OSCORE using ACE in OCF.
FP: Clarification. Client tries to talk to server, return 4.01 unauthorsized with the address of the auth server.

We agree that OSCORE can be used between Client and AS.

FP: once step 3.a is done and the derivation of the security context has happened, then it can be used.
PH: once you derive a new OSCORE sec context the old one is thrown away and you derive one from the current one.
FP: Yes
PH: How does it work in a reboot situation? I.e., what kind of information needs to be stored…
JS: you can also repeat 3c and 3e instead of 3g. If you use ACE you don't need 3g you can use a token.

PH: Showing slide 6. OSCORE using EDHOC.
Do you do RPK?
GS: Yes. What kind of RPK? Static-DH generates lower overhead than signature keys.
FP: When run OSCORE+EDHOC don't necessarily have DTLS.
PH: more for access and authorization of services (rather than access)
GS: can send messages with OSCORE right after handshake. On what need to store: master secret. Otherwise 4-way handshake is no good. Then also need to know what algos to use.
FP: need to have common context but might lose ID context. Then don't know what keys to use; will do another handshake to find out.
PH: important you store the master secret. Doesn't change. Just ID context changing when do 4-way handshake. Best to store recipient and sender ID. If can only store one thing, should store master secret
GS: right

Agreed on OSCORE and EDHOC use for OCF

PH: Showing slide 6. OSCORE appendix B2.
FP: What does OBT provision initial sec context? If they only get the "input material" and no identifier then they need to do 4 way handshake.
PH: Would insist on doing 4-way handshake. looking at configuring master secret sender and recipient IDs. All stored in memory, they should not be lost. When rebooting and starting with same sequence number it would be vulnerable to reply attacks.
GS: if lose seq number should do 4-way handshake. Problems storing them frequently, may miss one. Makes sense to do 4-way always.
PH: Agreed. Take it back to sec group at ocf for feedback.

GS: Appendix B1 discusses how to handle storage of sequence numbers during reboots.
FP: in case you have non-volatile memory, can store seq numbers

PH: Slide 8. Lots of answers to our questsions here already. How are we on time?
CB: We have the same time reserved tomorrow in case we want to continue the discussion.
(Slide contains Q&A)

PH: Implementations of Appendix B.2?
GS: yes, see backup slide for references. (B.2 is supported in californium, work in progress in aiocoap )
PH: Appendix B.2 lacks normative text which is needed for testing. Probably won't do detailed testign of B.2.
FP: Appendix B2 is not mandatory to implement, thus the lack of normative text. It has text that indicates that only if implemented, then the text is normative.
PH: Agreed.
PH: lenght of random values on B.2 are application specific. They will need to have a concrete minimum length (8 bytes). Random lenght makes it hard to determine which request is it.
GS: You could use another parameter cached (R2) to match the request. No need to use lenght.
PH:
FP: server is caching req from client, R2 from that client cached. When another request from that client, need to know if it is R1 or R2. Then match R2.
PH: when proxis in between, how can I tell which client?
CA: recipient ID (KID context)
PH: maybe missing something obvious; will come back to that. Need to understand how the differentiation can be done.

(question D)
FP: server does not initiate by itself; client sends request with ID context that server does not find (it is new ID context, step 1, or server doesn't recognize because it has lost state or something). Server replies to request; not sending anything on its own. (wihtout ID context) client would send req, server would reply with error then client would have to include context. If server doesn't have the security context, the 4way handshake starts.
PH: need to add step for this
FP: yes

Agreed to have another meeting tomorrow due to lack of time.

Action Points

• Ari to share recording.

• Ari to send meeting invite for tomorrow.

• JJ Look into how OSCORE "application payload" with the Auth Server is formatted.

Continuation 2020-03-19

PH: continuing on "Comments on RFC8613 [1/3]" A/B/C; checked whether they were resolved after yesterday (positive). Appendix B.2 looks like all works together nicely. Looked at complexity of B.1/B.2 with Oleg. B.1 (store sequence numbers) is simpler and probably appropriate for us. Take that to security WG for further feedback. 2^40 messages are plenty, have no worries of wrapping there. Nothing wrong with B.2, just going for the simpler solution.
PH: On question E (collisions between identifiers when using different ways to establish contexts). […]
GS: Same master secret for different pairs is a serious issue; why would that appear? In EDHOC you have no control over the master secret, as it's derived from ephemeral keys. In ACE, it's assigned.
PH: That's not the bit I'm worried about, more about collisions in the recipient ID. It's about inefficiencies because you try decrypting w/ multiple different keys.
GS: For case of one device talking to only one unit, that's what you can use short identifiers for; ID context can still be used all the time.
PH: That's the same like a long recipient ID
GS: If you like, yes
FP: If you do ACE first and then EDHOC with another, this should not be a problem. EDHOC lets nodes assign identifiers itself. Problem could happen with EDHOC first and ACE later, or ACE with several nodes.
CA: Can't the RS tell the AS a namespace of identifiers?
GS: We don't describe that in the ACE profile. Could maybe write something there.
PH: It'd work if the RS tells the AS a namespace, doesn't need to be in the specification, it'd be up to the RS which namespaces to pick (for ACE, directly configured solutions, etc). Is it worth having an agreed way to do that?
CA: rather up to RS and would not need global agreement
PH: We can take that approach in OCF and have our devices reserve initial namespaces. Then we forward-plan for devices supporting multiple protocols for establishing security contexts.
GS: Sounds good.
FP: Could be useful (but is not defined) that the namespace needs to be communicated between AS and RS, and keep that clear. [ unsure if captured correcty ]
PH: was hearing other way around, RS needs to reserve namespace and tells the AS
FP: Could also have a mechanism where the AS sets up the namespace, but it still needs to tell the RS. That's not part of the OSCORE profile, and not something that would be communicated in an ACE exchange. Not sure this is in scope for the ACE profile, but it's about how AS and RS agree on the namespace.
CA: would happen at time when AS and RS set up secure context. That is currently falling out of sky
GS: Could have an implementation note in the profile.
FP: Was there, removed
GS: Get it back.
PH: if we got application that does, needs to be application EDHOC. In other specs where talk about establishing these things needs to have namespace. If reserved for use in ACE then EDHOC is not to use that. Implementation note.
GS: makes sense.
PH: Will discuss in security WG, whether we'll have a fixed namespace or leave it up to the RS. Now that we know what you're planning, that helps.
OA: may make sense to reserve something, but we'll see

PH on comments F and G: G already addressed – can use B.2 – agrement was yes
FP: Didn't understand in the first place, there was confusion about the "sequential contexts"
PH: OK, to drive multiple contexts could resend nonces. Establish new master keys.
FP: Repost the token to the RS, and that triggers things.
PH: already in ACE spec that can resend token and nonces?
FP: Yes, as long as the token is valid – but will check.
PH: resetting replay protection – might already be mentioned?
FP: will check.
PH: think all Qs are answered. May end up confusing having 2 different ways to derive sequantial context. With nonces of B2. Don't think will cause us confusion, and if thought about it, that's good. But something to think about.
GS: When running ACE profile, don't see a reason to do B.2.
PH: true, no point implementing something additional. We may have already addressed multiple recipient context. Bit unclear what happens in .2; what should server do with multiple recipient context. But think addressed here. Is fine. Could be made a bit more clear. But if not posing problems, maybe not. To use OSCORE spec, always want to send error message and be clear that one SHALL send error message. Need to slightly adapt the text from what there's now. To make sure multiple context checked before error message. But maybe just minor inconvenience.
GS: No strong opinion on whether errata is needed here. Just to rephrase: There's text on how to handle multiple recipient contexts, and talks about going through each context. How to retreive the contexts is out of scope – you get identifier, you look up contents. When you get multiple matches, there's a note that this might be a B.2 case. We maybe should have another note about having multiple contexts. Great to have this clear in OCF spec, not sure what to do on our side.
PH: don't have strong opinion either. Just wanted to bring up.
GS: should we think abou this?
CA: we should say something about the situations where we talk about ID namespacing
GS: that's in ACE profile. This is in OSCORE RFC.
RH: could be good to mention in where retrieving context
FB: bit hesistant to make errata. It could have been more clear but this is not an error of the protocol itself. We didn't put it in 8.2 because it is not something all implementations need to do. Some don't need to. Don't have collision problem with IDs. Agree that would have been better to have implementation note, "you must reply with error" and be more specific, but not sure if errata is the right way to fixing these
CB: do know it's not the rigth way. It's not a bug. Just additional knowledge or considerations we have gained about good ways to use OSCORE. Incentive to start writing these down. Something that has happened often in sec area. We gain experience with protocols and good idea to write things down. Recently happened with JWT. BCP doc on how to use JWT because has been used in wrong way in many live systems. And if they ever revisit JWT they may move the material there. But don't see point for errata here on how to use this.
GS: so should write somethin down
CB: yes, should start a draft and start filling it in. Can be a live doc for a while. Good if authors of OSCORE and implementators would co-write the doc
FB: yes, good feedback. Want to write it somewhere
GS: something in LWIG was planned?
(CA offline now)

CB: LWIG is the right venue. Makes sense to collect this in one doc. And do as informal way as possible. When have critical mass can go forward.

CA (back): was about how optimizations of OSCORE interact with optimizations of CoAP.
CB: fun implementation notes doc
GS: have good ideas on how to collect different points on OSCORE. Maybe one draft.
PH: yes, sounds great. Let us know when developing and where we can follow the draft. Plan forward is really good. No more questions from our side. Wouter anything?
WB: did good job on expressing what we need.
PH: seems we have everything we need to know to complete our spec. Hopefully soon ready. Not sure if next appropriate time to synch but if have any major development on OSCORE with ACE, (EDHOC), or even TLS over ACE. We might use that; but not discussed yet. Anything that you think might be useful or major changes, please let us know. OCF people on this probably the best to contact.
FB: also github repo. Added now the two comments. If anything else that have comments, either contact ACE ML or us or put issue in Github. Happy to have any comment and feedback. Editor's copy the latest; currently same as the published I-D. Looking for handy diagram that found from RFC editor on process to get doc published if want to see that; if have less experience with the IETF.
PH: have some people at OCF who generally know how it works. Usually have someone who can help.
FB: all steps draft goes before publication and how far we are in the process
PH: can look into the figure (Francesca posted in chat). Just like how OCF protocol works :-)
FB: some delay after stable draft and publication

GS: question to OCF. Next to last slide. Group-com. Overlap or something.
PH: was meant to be group OSCORE.
GS: what means "Phil to show overlap"?
PH: more for internal; looking at group OSCORE as well, but was initially thinking it's something different. Now understand group OSCORE inherits all from OSCORE and just adds a few things. Wanted to make sure whatever we use in OSCORE, we don't have to implement something different for group-OSCORE.
WB: yes. When did investigation came to conclusion it's good to start with OSCORE for e2e sec. Group coms for typical case with set of lights and multicast set on lights. That's what understand multicast group OSCORE can do
GS: correct. Get's latency down. Also another use case "lock down schools" in US.
WB: have already mechanisms for group things. We did not standardize yet how to address messaging. Need to make sure what we send in multicast message is secure. Once have onboarded to OCF secure network everything should be done securely. Waiting for grou coms to progress. Now taking two step aproahc.
RH: group OSCORE on top of OSCORE is fairly easy
WB: will take a look on adding group coms. In general want to reference RFCs instead of I-Ds. Have been hurt a few times already with I-D changed. If RFC number known, probably good time.
PvdS: what is difficult is the management of groups. There's a draft on that.
WB: we have mechs for grouping. Just tying the distribution of keys to those groups. Not sure if want to use the same adding and deleting groups. Maybe for keys but on high level we have solution. But still debate at OCF aswell.

AK: seems we have now answers to all the questions and a way forward for the specs and communication. Any other issues to be discused before we close?

(none; meeting ended)