►
From YouTube: IETF106-ACE-20191119-1520
Description
ACE meeting session at IETF106
2019/11/19 1520
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
C
B
D
F
B
F
B
B
F
F
F
So
Version
three
has
it's
been
updated
following
reviews
of
version
two?
So
thank
you
very
much
Ludwig
and
Daniel
for
providing
those
reviews.
These
were
addressed
in
the
mailing
list
and
we
agreed
mostly
with
with
the
comments
we
had
and
we
have
incorporated
them.
Please
get
back
to
us
if
you're
not
satisfied
with
our
answer.
We
haven't
heard
anything
yet
so
we
assume
that
everything
is
fine.
F
Also
at
IDF
105
there
was
some
discussion
and
offline
chat
brought
mostly
from
Carsten
and
Jim
that
suggested
that
we
Resta
fie
our
interface.
So,
instead
of
relying
on
type
of
request
and
response
that
we
create
a
restful
interface
at
the
key
distribution
center-
and
this
is
the
major
difference
in
this
document
also,
we
did
what
I
think
our
major
improvement
on
up
in
Appendix
A,
which
specify
requirements
of
the
application
profiles
that
have
to
build
on
this
document.
F
We
also
got
a
new
review
from
Jim
of
version
3.
We
already
discussed
this
review
with
Jim
offline
and
we
agreed
on
a
way
forward.
There
is
no
major
problems
with
it
and
also
yesterday
we
got
the
review
from
Peter.
So
thank
you
very
much.
We
haven't
had
time
to
look
at
this
review
comments,
but
we
quickly
scan
through
I,
don't
see
any
major
issue
with
it.
F
I
don't
know
if
Peters
online,
but
if
he
is
anything
that
anything
is
worth
discussing
now,
please
come
and
comment
it,
so
we
can
do
that,
but
yeah
some
so
about
the
major
update,
Resta
fication.
So
now
we
we
define
an
interface
at
the
key
distribution
center
of
different
resources.
So
we
have
the
some
number
of
resources
under
these
ace
group.
/G
ID
g
ID
is
the
group
identifier
and
we
assume
that
it
key
distribution
center
maintains
one
resource
per
security
group,
and
this
resource
supports,
get
and
post
meta
method
get
would
get.
F
The
group
key
material
post
would
allow
a
node
to
post
its
own
public
key
to
the
key
distribution
center
and
the
response
will
return.
The
group
key
material
and
all
the
public
keys
of
the
nodes.
Other
resources
are
public
key
that
is
under
the
group
ID.
That
will
allow
a
node
to
get
all
the
public
keys
of
the
nodes
in
the
group
or
request
certain
number
of
public
keys
thanks
to
the
nodes
identifiers.
Then
we
have
policies
getting
the
group
policies.
How
these
are
the
finest
application
profile
dependent.
F
Then
there
is
something
called
context
number
or
CTX
num
that
allows
to
get
a
version
of
group
key
material.
This
this
number
is
incremented
by
one
every
time
the
group
is
Rashid
and
then
there
is
the
node
resource
or
endpoint
that
supports
get
and
post
methods.
A
member
would
do
a
get
to
these
resource
to
get
individual
key
materials
to
protect
outgoing
messages
or
it
would
go
at
post
to
request
to
leave
the
group
and
I
see.
Carsten
has
a
comment.
F
F
F
G
G
F
F
G
G
G
F
So,
okay,
we
will
add
that
thank
you
for
that
yeah.
So
this
is
what
we
did
so
far
and
then
we
got
we
defined
the
operations
that
by
specifying
what
endpoint
to
contact,
so
we
said
for
doing
a
joining
of
a
group.
You
do
this
request
for
doing
retrieval
of
updated
key
material
or
new
key
material
or
public
keys
or
group
policies
or
in
key
material
version,
etc.
We
define
what
method
on
which
resource.
F
So
we
have,
we
have
planned
the
update
of
version
four
following
genes
review,
so
the
main
difference
is
that,
instead
of
having
this
node
path,
we
will
now
have
one
node
resource
per
member
of
the
node
per
member
of
the
group.
So
before
we
had
just
a
node
path,
there
would
be
the
same
for
all
the
members
and
now
we're
gonna
have
a
different
one
for
each
member.
F
F
Instead
of
using
get
to
get
the
KDC
to
produce
and
return
the
individual
key
material
james's,
that
suggested,
we
use
foot
and
we
use
get
instead
to
get
the
group
key
material
plus
individual
key
material.
That
would
allow
also
to
observe
that
resource
and
finally,
instead
of
post
to
leave,
the
group
Jim
suggested
delete.
B
F
F
So
there
is
also
some
minor
or
other
comments
following
Jim's
review,
so
the
first
one
was
if
the
client
contacts
the
KDC
endpoints,
not
on
the
secure
channel,
it
gets
an
error
for
one
and
authorized
and
Jim
was
suggesting
that
we
include
the
AAS
creation
hints.
So
the
response
to
the
token
post
in
the
errors
payload,
we
thought
that's
a
good
idea.
So.
F
Another
comment
was
about
sending
the
array
of
certificate
instead
of
the
UI
of
key
repository,
refine
with
that
and
then
the
usual
finally,
the
using
fetch
instead
of
post.
So
we
go
ahead
and
do
that
and
also
we
got
the
comments
from
Peter
that
we
will
add,
but
we
didn't
see
anything
major
yet
so
yeah,
that's
it
unless
there
are
comments
or
questions
from
the
jabber
may
be.
B
G
F
I
think,
personally,
that
this
draft
has
improved
a
lot
with
this
update
and
it's
not
ready
to
implement,
because
we
want
to
do
this
next
update
first
and
once
we
have
processed
these
comments
for
this
update
and
Peter's
comments,
and
if
you
don't
get
any
major
objection,
I
think
we
that
would
be,
that
will
be
it
and
possibly
before
next
idea.
So.
G
I
would
propose
that
we
actually
in
the
front
matter
of
the
draft
at
some
point,
say
hey.
This
is
an
implementation
draft,
so
we
ask
people
to
implement
it
because
we
are
done
making
changes
on
our
own
and
we
know
would
like
to
make
only
changes
that
are
based
on
feedback
from
implementers
yeah.
That.
D
G
F
H
F
I
B
B
J
K
Reviews
gonna
happen
for
the
two
drafts
that
are
currently
in
publication
requested
the
profiles
for
DTLS
no
scar,
so
I
had
sort
of
been
playing
those
unhold
a
little
bit
while
we
were
working
through
the
comments
on
the
the
core
framework,
which
is
in
very
good
shape,
I
think
Ludwig
and
I
were
syncing
up
earlier
today
and
we
have
like
four
points
left
that
needed
a
few
tweaks.
So
it's
pretty
solid
and
we're
unlikely
to
need
more
changes
to
the
framework
that
will
require
cascading
changes
into
the
profiles.
So
I
should
unhold.
K
A
K
C
C
C
Market
order
from
rice
this
is
an
application
profile
of
ace,
also
working
document.
The
support
group
was
called
communication
and
it's,
of
course,
an
instance
of
a
scam.
That's
what
that
was
presented
before
here.
In
particular,
we
describe
how
client
can
join
an
Oscar
group
in
an
authorized
way
through
the
respective
manager
get
the
key
material
to
participate
in
your
communication,
secure
with
group
of
score
and
as
a
current
group
member
also
have
further
interaction
with
the
group
manager
to
get
latest
updated,
new
key
material
and
so
on.
C
According
to
this
flow
chart,
the
were
a
few
points
raised
at
the
previous
meeting
on
this
draft
just
quickly
not
on
them.
We
are
still
at
meeting
for
the
time
being
three
different
alternatives
for
the
join
node
to
agree
with
the
group
manager
on
the
exit,
algorithms
and
related
parameters
used
for
signing
in
the
group
that
we
believe
can
definitely
coexist.
C
We
solved
actually
the
other
three
open
points
on
how
to
signal
the
exact
encoding
protocol.
The
keys
in
a
group
and
how
the
client
can
prove
up
process
can
prove
the
possession
of
its
own
private
key
to
the
group
manager.
Upon
joining
essentially
through
a
challenge
from
the
group
manager
plus
it's
a
month-
and
we
are
also
now
mandating
that
the
group
manager
preserves
the
very
same
sender,
IDs
group
members
in
case
it
fully
Ricky's
and
the
group
of
course
thanks.
C
A
lot
for
the
review
gave
us
actually
right
during
the
the
past
meeting
that
we
processed
for
this
update.
On
top
of
that,
we
introduced
also
coordinating
with
SQL
comm
the
concept
of
group
name.
That
now
has
nothing
to
do
with
the
oscar
group
ID,
not
to
mention
we
were
tools
previously
use
0
by
the
and
so
on.
This
is
just
plain
important
identifier
that
is
used
to
get
the
access
token
to
present
the
group
manager
and
then
later
on,
to
refer
to
the
group.
The
journalist
was
just
renamed
as
group
membership.
C
This
is
also
lying
with
the
rest
base
product
considered
in
s,
click
on
that
Franchesca
presented,
and
we
reference
to
that
couple
of
details.
We
were
signalling
the
exact
encoding
publication
in
the
group,
considering
values
for
the
CWT
confirmation
method
registry.
So
we
we
get
rid.
We
got
rid
of
the
old
register,
we
were
defining
and
just
reusing
an
existing
one.
If
there
are
no
objections,
we
are
considering
to
recommend
the
size
of
8
bytes
for
the
challenge.
C
Nuns
returned
by
the
group
manager
they'll
be
aligned
essentially
with
a
choice,
and
there
is
now
in
the
oscar
profile,
and
we
got
the
question
from
jewish
out
actually
for
SQL
comm
that
we
think
of
specifying
in
profiles
like
this
one.
There
are
cases
where
the
group
manager
doesn't
actually
have
the
opportunity
to
return
announced
to
the
client
for
producing
a
signature
for
proof
of
possession
like
the
case
where,
in
the
first
profile
the
access
token
is
conveyed.
You
ready,
handshake
itself.
C
During
the
join
request,
same
thing,
we
think
recommending
an
8
byte
nouns.
We
clarify
that
signature
for
possessions
computing,
especially
using
the
very
same
signing
key
despite
the
journey,
not
in
the
Oscar
group
and
in
the
joining
response,
when
returning
public
keys
of
current
group
members
to
the
joining
node
here
comes
about
identifying
the
exact
associated
group
members,
which
is
something
the
Prophet
has
to
define,
and
here
we're
defining
that.
C
According
to
the
same
interface,
of
course,
it's
possible
to
ask
the
the
latest
key
material,
and
we
are
simplifying
that
as
happening
where,
for
instance,
enough
messages
are
failed
to
be
a
correctly
processed
or
verified
or
the
material.
The
material
is
expired,
and
we
are
also
exemplifying
the
case
when
a
group
member
can
get
back
to
the
group
manager
to
ask
for
new
individual
key
material
and
in
particular
we
say
a
new
sender
ID,
and
that
is
especially
the
case
when
the
sender
sequence
number
of
a
group
member
robz
around.
C
C
This
is
just
consistent
with
the
current
format
of
whisky
comm,
in
that
case
across
the
group
manager,
frees
up
the
sender,
ID
value
of
the
leaking
node,
and
unless
the
public
key
of
that
knot
is
used
in
another
group,
the
public
is
also
removed
when
it
comes
about
getting
public
keys
of
other
members,
either
get
all
of
them
with
a
get
or
specifying
a
subset
of
group
members.
The
request
in
all
these
interested
in
having
the
public
keys
again
identifying
them
with
respective
sender,
IDs
implementation
wise.
C
C
So
as
a
summary,
most
of
the
update
is,
of
course,
has
been,
of
course,
updating
this
draft
to
the
latest
redesign
in
SQL.
Defining
and
details
expected
from
profiles
of
SQL
come
a
few
open
points
we
have
in
my
not
address
for
the
next
update,
which
will
be,
of
course,
about
chasing
improvements
in
sto,
comm,
continuing
implementation
and
interrupting.
B
B
L
How
does
this
move
it
so
I'm
coming
to
it
after
some
time,
I
may
need
some
hand-holding
here.
Isn't
there
an
implicit
assumption
in
the
whole
design
that
all
the
group
members
use
public
keys
of
a
certain
type
or
is
it
like?
So
if
one
group
member
uses
public
keys
of
certain
curve
that
the
other
group
member
doesn't
care
about
what
happens?
It's.
C
L
The
group
member
can
say
that
you
are
not
allowed
to
join
the
node
because
you
don't
have
the
public
key
in
the
same
format
as
the
rest
of
the
group
members.
Correct,
I,
don't
see
this
documented
anywhere
in
the
draft.
I
think
this
is
a
big
big
assumption
that
every
group
member,
then,
would
use
the
same
curve.
So
even
if
some
of
the
group
members
have
moved
to
a
curve
that
is
stronger
if
there
is
one
or
few
that
that
use
a
weaker
curve,
the
rest
of
the
group
would
be
stuck
to
that.
L
B
C
Haven't
seen
like
that
so
far,
I
think
it
can
be
complicated
to
admit
that
every
group
member
can
do
whatever
he
wants.
Everyone
should
be
in
the
same
page
with
final
decision,
the
group
manager
that
can
in
principle
change
on
the
run.
The
type
of
public
is
enduring
calling
us
on,
but
everyone
has
to
converge
eventually.
B
L
I
think
it's
it's
fine.
As
long
as
you
document
it
so
just
say
that
the
group
manager
is
the
one
that
decides
when
we
move
to
the
stronger
crypto
curve,
for
example,
so
those
which
haven't
been
updated
won't
be
able
to
join
the
group,
but
this
is
something
that
still
worth
at
least
having
in
the
document
agree.
C
B
B
B
C
B
C
B
C
F
J
B
B
M
Good
morning,
at
least
for
me
so
I'll
be
presenting
the
MQTT
TLS
profile
of
ace.
This
is
Cheatham
Cheng
from
nominate
next
slide,
please.
So
after
the
draft
was
accepted
as
a
workgroup
item
in
Prague
in
ITF
104,
we
pushed
two
major
changes
based
on
Jim's
and
Daniel's
very
extensive
comments.
Thank
you
very
much
for
that.
I
highlighted
the
major
changes.
It's
just
sampled.
There
have
been
various
different
minor
changes
as
well.
M
The
first
version
in
the
first
version,
zero
one
we've
revised
the
order
of
how
we
present
the
different
versions
of
MQTT
and
the
solutions
we
provide
through
ace.
We
make
the
MQTT
version,
5
the
recommended
version
and
explained
the
interactions
for
MQTT
version,
3
wine
as
a
reduced
set
of
interactions
for
backward
compatibility.
We
also
clarified
which
endpoints
are
used
between
the
different
entities
in
version
0
2
again
based
on
Jim's
comments.
M
M
So
one
of
the
questions
that
was
raised
in
the
reviews
was
it
wasn't
clear
which
end
points
and
which
protocols
were
used
between
different
entities.
We
clarified
that
between
the
client
and
the
broker,
which
is
the
resource
server
in
our
profile,
we
mandate
the
use
of
mqtt
over
a
TLS
and
the
communication
is
published
subscribe.
M
We
also
use
HTTPS
between
client
and
authorization,
server
and
HTTPS
between
the
resource
server
and
the
authorization
server,
but
we,
of
course
accept
the
possibility
of
using
other
protocols
in
between
client
and
authorization,
server
and
resource
server
and
authorization
server,
including
co-op
I
mean.
Could
you
see,
but
it
was
out
of
scope.
The
description
was
out
of
the
scope.
The
reason
why
we
went
with
these
choices
when
we
were
describing
the
profile
was
looking
at
the
MQTT
broker,
implementations
in
the
practice
and
noticing
that
they
already
support
HTTP
based
back-end
communication
like
the
mosquito
broker.
M
We
basically
also
described
the
profile
with
the
JSON
encoding,
but
of
course
it
makes
the
ports
Ybor
and
we
followed
again
the
same
with
the
tokens
JSON
web
token
or
C
board
web
token,
with
proof
of
possession.
One
thing
that
needs
to
be
clarified
is
based
on
the
discussion
between
high
nests
I,
think
that
was
raised.
M
Whether
the
descriptions
for
pop
for
jot
is
at
the
same
maturity
as
in
this
workgroup
and
whether
we
have
to
be
making
more
clarifications
or
waiting
on
other
solutions
from
other
work
groups
next
slide,
please,
and
for
the
client
in
a
second
for
a
version
version
or
two.
The
major
clarification
was
on
how
the
client
authenticates
and
authorizes
to
the
resource
server
and
looking
at
the
different
options
through
TLS
and
MQTT,
and-
and
this
was
a
table
of
course,
produced
by
Jim
as
well.
M
We
basically
looked
at
the
four
options,
the
case
where
there
is
no
authentication
in
either
of
the
layers.
This
represents
the
public
topics
where
there
is
no
permission
required
to
publish
or
subscribe,
and
also
it
describes
the
case.
We're
all
set
info
following
the
security
properties
of
the
core
draft
indicate
the
recommended
and
described
authentication
method
is
in
the
in.
The
draft
is
anonymous
over
TLS
and
ace
authentication
in
for
the
client,
where
the
client
provides
the
token
during
connecting
to
the
mqtt
server
broker.
M
We
also
support
the
case,
where
token
is
not
provided,
and
this
triggers
AAS
discovery
for
the
case
where
the
authentication
is
done
at
the
TLS
layer,
we
basically
have
the
same
descriptions
based
on
the
DTLS
authorized
draft,
where
there
are
our
PK
or
PS
game
modes,
supported
in
the
case
of
our
PK.
The
token
must
be
provided
through
the
outset
info
before
attempting
the
connection
and
for
the
PS
K.
It
can
be,
of
course,
provided
over
the
PS
k
identity.
M
When
both
are
used
to
authenticate
the
client,
we
say
we
should.
This
should
not
be
done.
This
is
over
authenticating.
The
client,
and
we
described
it
as
token
in
connect-
would
overwrite
any
permissions
during
the
TLS
handshake
next
slide,
please
for
the
outside
info.
This
was
described
in
the
appendix
as
a
possible
solution
if,
when
the
authentication
is
happening
over
TLS,
this
follows
the
similar
descriptions
in
the
DTLS
profile,
where
it's
the
same
security
properties
as
well.
M
M
However,
there
is
a
slight
meaning
difference
here,
because
in
MQTT
they're
not
authorized
represents
that
the
publish
message
is
not
authorized,
not
that
the
token
is
not
valid,
so
there
might
be
something
to
consider
here
to
clarify
in
the
draft
and
the
broker
stores
and
indexes
all
the
tokens
and
then
find
the
clients
during
the
connection
based
on
this
index.
Next
slide,
please
for
the
case
that
we
describe
and
recommend
in
the
draft
the
authentication
during
the
ACE
and
MQTT
handshake.
M
When
the
client
sends
the
first
connect
message,
we
assume
that
they
took
that
there
are
two
ways
to
do
it.
The
first
case
where
the
client
passes
the
token,
as
well
as
it's
work
on
tongue
challenge
to
the
broker
and
then
using
this
proof
of
possession
information.
The
broker
validates
the
client
and
the
second
option
is
a
challenge
response
handshake,
but
where
the
client
passes
only
the
token
to
the
broker
and
then
broker
challenges
the
client
and
expects
a
response
that
it
can
validate
the
proof
of
possession.
M
We
described
two
cases
because
the
first
one
is
the
only
available
one
to
the
Infinity
version.
Three
one,
one
mqtt
version
three
one
one
does
not
support
a
challenge
response
flow,
but
it
can
be
supported
in
the
MQTT
version.
Five
based
on
Jim's
recommendations,
we've
considered
the
challenge
to
any
using
to
communicated
through
the
TLS
exporter
and
things,
but
we
decided
here,
as
was
this.
You
know
also
raised
by
the
previous
presenter
whether
this
challenge
input
should
be
configurable
should
what
lengths
should
be
recommended.
M
I
was
thinking
16
bytes,
but
maybe
it
is
to
come
to
a
group
consensus
or
what
we
recommend
in
terms
of
challenge
sizes
and,
of
course,
we
will
also
need
a
group
input
on
whether
we
describe
this
correctly
and
what
kind
of
labels
we
should
be
registering
for
the
TLS
exporter
label.
The
same
length
issue
also
is
open
for
the
challenge
response
flow,
which
is
the
second
option.
Next
slide,
please,
for
just
completeness,
like
I'll,
describe
the
case
where
there
is
no
token,
but
the
method
of
authentication
is
a
nice.
M
In
that
case,
the
broker
will
return
and
not
authorize
connection
acknowledgment,
and
it
will
use
the
user
property
in
MQTT
defined
for
the
broker
to
provide
additional
information
to
the
client
and
AS
creation
hints
and
be
put
in
here
again.
This
is
not
possible
for
MQTT
version
3.1,
which
doesn't
allow
additional
information
to
be
put
into
connect,
so
it
will
be
just
a
disconnect
and
not
authorized
for
infinity
version.
Three
one.
One
next
slide,
please.
M
So
at
the
moment
we
basically
revised
extensively
the
draft
based
on
the
chairs
comments,
and
we
basically
think
that
there
should
be
some
clarifications
needed
in
the
way
that
you
know
length
of
the
challenges
and
the
TLS
exporter
labels
and
whether
we've
explained
the
different
encodings
correctly
and
how
the
proof
of
possession
is
done.
I
think
that
needs
it
still
checked
up
a
bit
more
and
implementation
wise.
There
isn't
prototype
implementation
for
NPT
version.
M
Three
one
one,
but
we've
started
a
collaboration
with
Edinboro
University,
which
is
looking
at
implementing
the
NPT
version,
5
version
and
I
think
Jim
is
also
working
on
an
implementation,
a
question
to
the
group
whether
the
draft
should
stay
at
quantize
like
this
or
should.
It
also
include
the
payload
encryption
for
the
published
message
based
on
the
group
comb
draft.
So
those
are
all
I
would
like
to
present
today
to
you.
F
A
F
F
C
Right
on
the
right
side
that
proof
of
possession
mode,
so
you
returned
the
challenge
and
rated
by
the
broker,
and
you
sign
or
Mac
that
challenge
alone
yeah.
You
may
consider
what
we
are
doing
in
in
the
profile
I
presented
before,
where
something
similar
happens,
but
what
the
client
signs
is
actually
that
challenge
concatenated
with
announced
it
generates
of
its
own.
Oh
I,.
C
C
M
The
publish
message-
this
is
basically
addressing
the
comment
where
the
broker
sees
everything
that
is
published
as
a
payload
to
a
topic.
In
that
case,
the
only
the
payload
will
be
encrypted
and
the
published
topics
will
be
visible
and
only
the
clients
that
are
authorized
to
read
what
the
message
is
about
can
read
it,
but
they
can
still
discover
the
topic
itself,
so
it
won't
affect
the
topic
discovery.
It
won't
affect
the
fact
that
broker
knows
it's
received
messages
to
that
topic,
but
it
will
affect
the
brokers
ability
to
read
those
messages.
Okay,.
M
L
K
Yeah,
so
the
idea
is
that
this
is
a
very
time
limited
challenge,
and
so
you
get
sort
of
you
get
you're.
Getting
like
the
channel,
binding
sort
of
property.
The
attacker
would
need
to
guess
the
exact
value
so
uniqueness
as
opposed
to
collision
resistance.
So
you
don't
need
the
birthday
attack
at
the
birthday.
Paradox
attack,
strength,
reduction
and
because
we're
in
a
constrained
environment
you
want
to
save
the
bytes.
K
Basically,
we
already
have
precedent
for
using,
like
the
eight
by
authentication
tag
for
CCM
and
like
I'm,
not
super
happy
about
it,
because
I'm
used
to
the
the
big
iron
cases
very
confuse
the
big
novices
and
not
have
to
worry
about
it.
But
given
all
the
president
I
think
the
the
trade-off
is
likely
to
end
up
at
eight
bytes.
B
K
L
M
B
B
J
J
B
F
So
yes,
first
document,
that
is
not
a
working
of
document
of
this
session.
The
pub/sub
profile
for
ace
I
just
wanted
to
add
the
slide
about
motivation
and
a
quick
recap.
So
this
document
defines
how
to
use
ace
to
authorize
nodes
and
Parisian
keys
for
co-op
pub/sub.
It
also
defines
how
to
protect
coops
of
communication
using
those
keys,
and
this
second
part
can
definitely
be
applied
to
mqtt
as
well,
so
it
was
submitted
the
first
time
at
IDF
98,
so
it
has
seen
quite
a
few
review
updates.
F
F
F
So
I
only
have
this
slide.
The
status
is,
the
document
is
updated
version
six
complies
with
a
ski
group
comm.
There
is
a
plan
up
data
version,
seven
which
is
keep
the
key
to
the
update
to
comply
with
a
ski
group.
Comm
we
would
like
to
or
I
would
like
to
clarify
and
expand
on
the
fact
that
the
protection
of
content
applies
to
MQTT
pub/sub,
as
well
as
co-op
pops
up
right.
Now,
it's
not
it's
possible,
but
maybe
it's
not
clear
enough
in
the
document.
L
A
L
Yet
again,
can
we
go
back
to
the
previous
slide,
so
I
understand
that
coop,
ops
of
an
mqtt
pops
up
are
different
or
there
is
some
some
details
that
are
different,
but
architectural
II
there's
a
publisher,
there
is
a
broker
and
there
is
a
there.
Are
subscribers,
so
is
like
I'm
trying
to
understand.
Okay,
the
difference
between
how
the
keys
are
used
for
MQTT
so
and
and
let.
F
Me
just
say
something
that
yeah
I
try
to
express
in
previous
meetings,
but
it's
good
to
recap
here
as
well.
This
draft
is
basically
two
parts.
The
first
part
is
a
profile
of
coop
pub/sub,
as
MQTT
has
a
profile
for
MQTT,
and
the
second
part
is
how
to
use
those
keys
to
protect
the
content
of
the
publication
and
that
part
is
applicable
to
both
MQTT
and
pops
up,
because
they're
all
pub/sub,
so
you
can
use
that
and
we
did
have
discussion
before
we
go
back
to.
Should
we
split
it?
Should
we
not
split
it?
F
Should
we
keep
it
together?
Should
we
adopt
one
to
both
I,
don't
know
so
we
had
this
discussion
before
and
the
result
was
yes.
We
want
this
or
I'm
recapping.
What
you
know
you
can
find
in
previous
meetings.
Good
feedback.
Yes,
we
support
this.
No
do
not
split
it,
because
this
is
simple
enough
to
have
in
one
document.
L
F
F
G
F
G
F
G
Know
generally,
yes,
you
can
use
that
yeah.
That's
what
I'm
aiming
at
that.
The
very
old
part
here
really
is
the
the
content
interruption.
So
if
I'm
using
0
mq
with
norm,
which
is
a
reasonable
way
to
do
pops
up
I,
this
is
really
just
multicast
groups
and
and
some
people
central,
the
Marty
has
proven
some
other
people
are
receiving
from
the
multicast
group.
Can
I
go
ahead
and
use
this
yeah.
H
Seek
them
from
the
jabber,
the
name
of
that
draft
is
pops
up
something-something.
Will
that
change?
If
it
also
describes
stuff
applicable
to
MQTT?
She
was
under
the
impression
that
this
or
rad
the
stuff
are
applicable
to
amputee
t
like
the
payload
encryption
would
be
described
in
the
mqtt
TLS
profile.
H
F
F
F
So
I
mean
we
discussed
it
before
in
a
previous
meeting
me
and
her
write
that
this
is
applicable
to
both
like
this
can
be
reused
in
in
MQTT
I.
Just
put
it
there,
because
I
thought
that
was
the
simplest
thing
to
do
to
have
it
in
the
same
draft,
but
before
like
I
mean
this
is
not
even
adopted
working
group
document
I
would
like
to
get
it
there
before
we
can.
We
think
about.
F
A
G
Kirsten
yeah,
so
the
question:
what
do
we
put
where
and
when
and
so
on,
mostly
is
a
question
of
timelines
and
who
gets
normative
reference
as
to
what
and
so
on
so
III
think
that
should
be
solvable
the
question
really.
That
is
not
entirely
clear
to
me.
Yet
maybe
that
also
was
behind
Jim's
question
was.
G
F
G
F
D
B
So
my
guess
is
well
I
think
there
is
no
need
to
hum
because
I
don't
see,
I
mean
I,
don't
see
any
purpose
of
having
a
ham
here.
We're
gonna
provide
we're
gonna,
send
that
to
the
mailing
list
and
so
well.
What
I
like
is
that
a
few
more
people
read
the
draft
and
who
would
like
to
commit
to
review
the
draft
once
adopted.
B
B
F
F
C
Market
Lanka:
this
is
another
profile
vase,
but
the
transport
profile
vase
in
the
original
sentence,
like
your
score
profile
or
details
profile,
and
this
is
about
enabling
a
client
and
the
resource
server
to
communicate
using
Oscar
or
grupo
score,
especially
at
the
previous
meeting.
We
were
asked,
especially
to
clarify
the
applicability
and
the
need
for
this
and
to
fix
a
possible
vulnerability
for
impersonation
attacks.
C
So
why
do
we
need
this?
You
have
group
of
score
for
secure
communication
among
group.
Members
point
is:
how
do
you
enforce
access
control?
A
given
group
member
access,
the
resources
at
another
group
member
in
a
group,
and
you
don't
need
to
do
big
things
in
some
simple
use
cases
where
essentially
being
authorized
to
access
a
group
and
get
in
the
group.
Key
material
is
essentially
fine
to
be
authorized
to
do
anything
at
any
resource
at
any
group.
Member
and
you're.
C
Just
fine,
it's
not
fine
in
other
use
cases
with,
we
need
something
more
complex
and
you
need
to
individually
authorize
each
client
to
do
particular
things
at
other
group
members.
Essentially,
you
want
to
distinguish
different
clients
per
different
access
rights.
They
are
supposed
to
have
practical
examples
that
we
improved
in
the
introduction
of
the
draft.
C
First
example
thing
of
a
set
a
group
of
logs,
and
you
want
some
class
of
clients
to
be
able
to
check
the
status
of
locks
only
while
other
clients
can
be
able
to
check
the
status
and
also
change
it
so
think
of
different
kinds
of
users
like
children
or
parents,
or
especially,
you
want
the
logs
to
actually
act
as
servers
only
so
not
to
be
able
to
open,
lock
other
logs
in
the
first
place.
A
more
complicated
use
is
really
the
building.
Automation
was
provided,
but
they
problem
from
botnet.
C
There
are
bug
net
applications
where
you
may
have
a
class
of
clients
like
light
switch
that
are
supposed
to
perform
only
low-priority
commands,
while
fire
panels
can
perform
essentially
any
kind
of
emitted
commands
plus
set
the
system
at
the
status
where
only
high-level
authorized
clients
can
perform
high-level
operations.
Essentially,
you
want
to
enforce
the
different
categories
of
client
to
do
all
the
things
they're
supposed
to
do
so.
C
You
need
fine-grained
access
control
that
you
can
in
fact
achieve
using
ace,
and
that
being
said,
then
you
have
a
problem,
because
current
profiles
of
ACE
don't
enable
a
client
and
resource
server
to
use
group
secure
communication.
Even
if
you
consider
the
Oscar
profile
you
go
for
it,
a
client
post,
an
access
token
to
a
server.
They
establish
a
no
score
context.
C
They
can
use
Oscar,
but
at
the
same
time
they
cannot
legitimately
use
group
or
score
as
an
alternative
or
at
the
same
time
they
have
to
stick
to
the
single
protocol
indicated
by
the
profile
score
so
bottom
line.
You
cannot
have
together
group
of
score
for
secure
communication
and
fine-grained
access
control
and
for
three
days,
and
this
profile
is
exactly
about
fill
in
this
gap.
It
builds
over
the
Oscar
profile.
C
Latest
version
essentially
admits
to
communication
protocols
in
the
same
profile
or
score
and
group
of
score,
assuming
both
parties
are
already
in
the
correct
Oscar
groups
so
like
in
the
Oscar
profile.
First
of
all,
they
establish
a
pairwise
Oscar
context,
of
course,
and
then
the
idea
is
to
first
bind
the
access
token,
not
only
to
the
pairwise
context,
but
also
the
group
context
and
second,
to
bind
the
pairwise
context
also
to
the
group
context.
So
you
achieve
the
same
properties.
C
You
have
from
the
Oscar
profile,
plus
essentially
proof
of
group
membership
of
the
client
thanks
to
the
binding
between
the
token
and
also
the
group
context.
How
is
this
achieve
it's
about
slightly
extending
the
messages
of
the
Oscar,
Pro
fellows
and
essentially,
and
the
derivation
of
the
pairwise
context.
C
So,
in
the
access
token
request,
the
client
provides
the
es,
also
the
it
uses
in
the
Oscar
group,
the
group
identifier
and
its
own
public
key
together
with
the
signature
completed
on
something
the
slide
using
its
own
signing
key,
essentially
to
prove
the
AES
possession
of
its
own
private
key.
What
the
sign!
Well,
what
we
are
proposing
is
using
something
related
to
that
secure
association
between
client
and
authorization
server,
for
instance,
if
they
are
communicating
using
the
TLS
they
can
assign
an
exporter.
C
This
is
essentially
the
outcome
of
input
and
discussion
with
Jim
in
order
to
avoid
a
naughty
group
member.
Another
group
member
in
the
same
group
of
this
client,
essentially
impersonate,
is
client
using
the
wrong
sender
ID.
At
least
this
way
you
are
providing
the
resource
server,
with
an
opportunity
to
check
that
the
public
key
in
the
token
actually
matches
with
a
sender
ID
that
comes
in
the
token
in
the
salt
parameter.
C
It
was
indicating
in
the
access
token
the
salt
is
composed
also
of
the
sender
ID
of
the
client
in
your
group
and,
if
not
empty,
the
masters.
Although
the
Oscar
group,
the
master
secret,
is
composed,
considering
not
only
the
master
secret
indicating
with
the
token
but
also
the
master
secret
of
the
group,
and
then
the
context
is
just
derived
according
to
the
derivation
procedure
of
Oscar
as
an
example.
That
of
course
hides
a
lot
of
all
of
the
low-level
details.
C
Here
we
have
a
client
series
for
servers
assuming
all
of
them
already
in
the
oscar
group.
The
client
asks
for
an
access
token,
so
indicating
also
its
own
sender,
ID
in
the
oscar
group
and
the
group
idea
of
the
group
and
that
information
is
echoed
back
also
in
the
access
token,
then
the
client
posts
the
resource
server,
one
exchange,
if
Nancy's
derivation
of
the
pairwise
Oscar
context
as
described
below.
C
Well,
the
client
repeats
the
very
same
procedure
to
post
an
access
token
to
our
sto
and,
of
course
the
Scopes
here
can
be
different
in
the
T
requested
access
token.
They
also
derive
a
pairwise
context
and
at
this
point
well,
we
are
admitting
by
construction
in
this
profile
that
it's
fine
for
the
client
to
communicate
with
the
resource
servers,
either
with
Oscar
or
with
group
of
score,
and
in
this
example,
there's
a
first
Oscar
request
to
our
s1,
followed
in
by
a
multicast
request
targeting
the
whole
group,
so
both
our
s1
and
rst.
C
So
it's
a
new
proposed
transport
profile
of
ACE,
essentially
for
having
fine-grained
access
control.
As
expected
in
ace
plus
clientele
resource
servers
that
can
use
model,
your
score
has
only
possibility
right
now,
with
the
profiles
available,
but
also
group
of
score.
It's
supported
by
at
least
one
real
world
use
is
coming
from
back
net
and
we
are
essentially
pairing
the
group
in
the
pairwise
context,
as
well
as
the
token
with
also
the
group
context.
C
K
This
is
been
kenick,
so
I
have
to
apologize.
I
was
just
looking
at
this
stuff
for
the
first
time
like
today
and
I'm,
you're
generally
in
favor
of
fine-grained
access
control
and
whatnot,
and
all
this
good
stuff
I'm
just
trying
to
understand,
basically
why
we
need
both
this
and
the
stuff
we
already
have,
and
is
it
may
be
that
there
are
some
devices
or
situations
that
can
do
the
sort
of
base
group
communications
with
us
car,
but
they
can't
do
this
or
just
it
takes
time
longer
to
develop.
C
K
C
In
production-
and
one
of
them
is
actually
coming
from
buck
net,
where
they
can't
imagine
a
problem
like
this,
with
different
classes
of
clients
that
you
need
to
do
or
not
do
different
things.
So
you
won't
go
enforce
this
level
of
granularity
for
access
control.
So
you
need
something
like
ace
right.
K
C
J
B
C
B
B
Francesca
got
the
names
of
the
people
that
committed
so
yeah,
so
I.
Think
next
step
is
to
maybe
update
a
little
bit
a
draft,
but
I
mean
don't
overkill
and
then
I
mean
more
people
need
to
review
before
we
can
proceed
to
the
adoption.
I
think
that's
the.
If
anyone
is
find
the
draft
I
mean
use,
less
I
mean
they
have
to
stay
it
as
a
as
soon
as
possible.
B
B
C
Just
a
few
words,
this
is
another
restful
interface
for
the
oscar
group
manager.
This
is
not
intended
for
candidate
group
members
or
current
group
members,
like
the
profile
we
presented
before.
This
is
intended
for
an
administrator
that,
as
the
first
thing
wants
to
create
those
core
groups,
set
update
their
configurations
and
parameters
and
possibly
delete
oscar
groups.
C
It
essentially
describes
resources
in
the
group
manager
for
doing
that
and
operations
on
them
for
an
administrator
acting
as
client.
That,
of
course,
is
to
get
an
access
token
to
be
able
tries
to
do
that
at
the
group
manager.
First
of
all,
the
idea
is
very
much
inspired
to
latest
intended
redesign
of
the
APS
for
a
co-op
pops,
a
broker.
In
fact,
you
can
see
in
this
picture
on
the
group
manager.
C
We
propose
that
a
single
clip
collection
resource
and
then
one
group
confirmation
resource
for
each
created,
active
Oscar
groups,
so
essentially
on
the
group
collection
resource.
You
can
send
a
get
to
retrieve
the
list
of
active
groups
or
you
can
send
the
post
to
create
a
group
specifying
the
name
and
its
configuration
parameters
and
we
are
defining
how
to
default.
C
H
So
very
quickly
draft,
basically
it's
about
being
able
to
get
notified
when
a
token
affecting
you
gets
revoked.
So
the
idea
is,
when
token
is
revoked,
the
client
or
the
research
server
that
is
affected
by
that
token
wants
to
know
about
that,
and
why
are
we
not
revoking
tokens
at
the
moment?
There
is
a
draft
RFC
in
off,
but
it's
about
the
client
revoking
its
own
tokens
when
it
doesn't
need
them
anymore,
but
in
IOT
space
we
think
there
are
use
cases
where
the
AAS
or
the
resource
owner
would
want
to
revoke
tokens.
H
And
then
how
did
the
client
and
the
resource
server
learn
that
and
the
idea
is
when
you
register
a
client
or
a
resource
server
at
the
authorization
server.
You
create
a
resource
and
this
resource
is
gettable
or
get
observable
in
coop
by
the
client
or
the
resource
and
on
this
resource
the
AAAS
publishes,
which
tokens
are
revoked
and
not
yet
expired.