Minutes IETF106: ace
minutes-106-ace-00

Minute takers:
    Ludwig,
    Jim,
    Ryo

* Welcome

Current Drafts
* Any time needed for AD comments
* draft-ietf-ace-key-groupcomm

(quick recap slide)

Updates in version 3
please comment if there are any concerns

Major update: RESTification
ace-group/{gid}

Carsten (CB): 3 pairs of get/post there. First and third are idiomatic, second
is the case that we designed FETCH for. -> Addressed in a different slide, POST
to retrieve pks of nodes seems wrong. FETCH or PUT? Francesca (FP): Isn't FETCH
optional? CB: Just as optional as POST, use FETCH not workarounds, requires
just little code to support FP: ok, will go ahead and make that change

(FP): difference in v4:
    1 resource per member of group below node
    PUT to get the KDC and return
    DELETE instead of POST to leave

    If no objection will go forward with proposed changes
    Daniel: Feel of the room? Any opinions?
    Room: <Silence>

Other updates:
    Every node will need a node name
    URI of cert instead of key repository
    change of method (as in the question from CB)

Daniel (DM): Questions/comments on how to move on with the draft?
CB: quite useful to know if quicksand or ready to implement
FP: Not ready to implement before next update
CB: Say if ready to implement in the Front Matter of the draft
DM: Do you want to implement as soon as it's ready? -> CB: Yes

Jim Schaad (JS): Two versions before stable.  On which version will it be
considered stable? FP: possibly at version 5

JS: With major architectural updates, we might expect more major changes in
version 4 and 5

DM: When to expect V4?
FP: December/January

* General WG
Ben Kaduk (BK): Question by Jim on when AD reviews are to be expected
 draft-ietf-ace-oauth-authz almost done (discussed with Ludwig in side-meeting)
 draft-ietf-ace-oauth-parameters almost done (pending small update rippled over
 from previous)
profiles (draft-ietf-ace-dtls-authorize, draft-ietf-ace-oscore-profile) after
two other drafts in personal review-queue. Expect ~3 weeks from now.

* draft-ietf-ace-key-groupcomm-oscore
Marco Tiloca (MT) presenting

(recap) draft on how a client can join in an oscore group in an authorized way

(summary of open points solved since ietf105)

recommend a size of 8 bytes for "rs_nonce" (challenge to sign) if no objection
also recommending 8 bytes for client-generating "cnonce"
Ok to use TLS-exporter as rs_nonce?

(slide on current implementation)
Ludwig Seitz: The URL on the slide not correct anymore. It's
https://bitbucket.org/marco-tiloca-sics/ace-java now

DM: What is the size of the TLS exporter? expected to be longer than 8 bytes

Mohit Sethi(MS): Common public keys needed for the group?
MT: It's up to the group manager to make the decision of which curve/signature
algorithm is used by group MS: Not documented in the draft. MS: Big assumption
that all group members will use same curve, should be documented MS: also on
crypto-agility: we might be stuck to a certain curve if members aren't updating
MT: everyone has to be on the same page, everyone has to update (if the group
manager specifies so) MT: Fine as long as it is documented. DM: Also provide a
recommendation on designing the node (to do curve updates when needed)

JS: The exporter allows you to set the size for exporting

* draft-ietf-ace-mqtt-tls-profile
Cigdem Sengul (CS) presenting

(protocols and encodings slide)
reasoning: MQTT brokers in practice supported HTTPS back-channel
clarify relation to pop4JWT
major clarification: how the client authz/authns
recommended: Anonymous over TLS and ACE over MQTT
provides token in CONNECT, triggeers AS-Discovery
using both TLS and ACE SHOULD NOT be done

in MQTT, "Not Authorized" means PUBLISH did not succeed, not that the token is
invalid -> may need clarifying in further drafts

MQTTv3.1.1 does not support the challenge-response flow, making it the only
option

AS Discovery: Add AS creation hints in CONNACK. Not supported in MQTTv3.1.1
only for MQTTv5

FP: Encryption is not in ace-groupcomm, it is in pubsub. Will be good to have
in MQTT as well (support adding it) Jim (from Jabber): It can be done in a
separate draft. Recommendation was not taking it out of pubsub (in previous
meetings). MT: consider to sign/MAC the server challenge concatenated with a
client-generated nonce

MS: What's the use case for encrypting the PUBLISH message?
CS: Only the clients authorized can read it. Brokers cannot read the messages
themselves but still supports discovery, publish and subscribe on the topic

Discussion on recommeded size of nonces,
CS: Does the group have a recommendation?
Ben Kaduk (BK): It's a transmission cost trade off
CS: Should it be configurable with minimum size
BK: Configure per broker/group/??? ?
CS: More on per broker basis
BK: Maybe it is a little bit too much flexibility, but we can discuss later

DM: Hearing that having 8 bytes is not a problem here. correct?
room: <silence>

DM: Next version December, at least 2 more versions before WGLC (1 in Dec and 1
in Jan), group needs time for review

Proposed Documents
  Draft-palombini-ace-coap-pubsub-profile
Francesca Palombini (FP) presenting

(recap/motivations) how to authorize nodes and provision keys for CoAP pubsub,
protect CoAP pubsub communications

MS: understands that CoAP pubsub and MQTT pubsub are different,
    but conceptually the same, trying to understand the differences
FP: first part is profile for coap pusbub, and second part is protecting pubsub
using the keys. The second part also works in MQTT pubsub. There were
discussions on splitting the document.

CB: When another pubsub comes up, what will we have to do?
FP: The second part of the document will apply.
CB: Can we use it right away? Do we need the "glue"?
FP: Should work right away with any pubsub. This is about encryption of content.

CS (from Jabber): The name of draft says CoAP, would the name change if it can
be applied to other pubsubs? FP: The name uses CoAP because it was born as a
CoAP profile. Jim (from Jabber):  I would like to see a single content
encryption format for both versions and not different for each FP: Would like
to clarify that it's not only CoAP and can also be applied to MQTT CS: Please
make it so that MQTT implementers can find this document

DM: Objections for draft being adopted? Anything against draft being adopted?
room: <silence>
DM: Will send to mailing list, move to adoption
(got 4 reviewers from the room when draft is proofread and ready) + Cigdem

(from Jabber, there was a three +1 on who read the draft)

FP: Keep it as one document for now

  Draft-tiloca-ace-group-oscore-profile
  Marco Tiloca (MT) presenting

(motivation)
how to enforce access control for resources at group members?
use cases. group of smart locks, building automation (BACnet)
current profiles does not support secure group communication between C and RSs

(contribution)
-> New Group OSCORE profile of ACE

BK: Generally in favor of the concept. Wondering why we need both this and the
stuff we already hav. May be overkill for the use cases stated. If we did this
document and threw away other documents who will be sad? MT: The documents
presented before are about being authorized to join the group, i.e. get the
keying material from the Group Manager. This document has no overlapping with
that and describes what happens after that, i.e. a current group member
asking/showing authorization to access a resource at another current group
member, also with secure group communication that current other profiles do not
allow. In the next version we will clarify the sequence of events and what
belongs to what document. DM: Who read the draft? Jim has read the draft, but
cannot remember the content at the moment BK knows the feeling ... Göran
Selander will read the draft JS will review in next couple of weeks

(ran out of time here, quickly going through the rest of the drafts)

  Draft-tiloca-ace-oscore-gm-admin
    Marco Tiloca (MT) summarizing

    RESTful interface of the OSCORE Group Manager, for administrator of OSCORE
    groups to create/configure/delete groups

  Draft-tiloca-ace-revoked-token-notification
Ludwig summarizing

being able to get notified when token is revoked
C or RS wants to know about that
in IoT AS or Resource Owner may want to revoke token (in comparison to OAuth
where client revokes token when not needed anymore)

(missed the last question)
??: Does this work for big hardware or is just for CoAP
LS: currently only defined for CoAP - could be extended to HTTP as well.

* AOB