►
From YouTube: IETF105-ACE-20190725-1740
Description
ACE meeting session at IETF105
2019/07/25 1740
https://datatracker.ietf.org/meeting/105/proceedings/
A
C
D
F
E
F
Basically,
since
we
met
last
time,
we
all
of
the
documents
that
we
had
been
working
on
have
now
gone
to
the
area
director
and
if
the
earlier
director
was
here,
which
he
seems
to
have
not
decided
not
to
show
up.
The
first
thing,
I
do
is
be
saying
so:
ban
winner,
we
actually
get
80
reviews
on
these
documents,
which
he's
gonna
say
well.
He
started
on
the
first
one.
G
F
H
Hi
everybody
today
I
am
presenting
the
key
provisioning
for
group
communication
using
ace.
This
is
a
working
group
document
version
2.
So
a
quick
recap
for,
if
you
haven't
seen
this
before
these
documents,
specify
how
to
use
the
ACE
framework
and
profiles
to
provide
authentication
authorization
and
an
key
distribution
to
notes
joining
a
group.
So
the
first
part
of
the
exchange
here
is
a
message
flow
from
from
the
document.
H
The
first
part,
the
client
is
I,
know
that
wants
to
join
the
group
contacts,
the
a
s
through
the
ACE
or
the
ACE
exchange
with
the
AES
and
the
KDC
posterization
token
to
the
KDC.
Kd
c
stands
for
key
distribution
center
and
then
afterward
contacts
the
KDC
to
get
the
keys.
So
this
through
a
distribution
request
and
response.
H
H
So,
first
of
all
status,
update
of
version
2
and
I'm
gonna
go
through
the
sub
date
quickly,
but
we
would
like
some
feedback
from
the
working
group.
All
these
updates
come
from
review
by
jim,
so
we
have
implemented
these
changes
based
on
his
review
and
he
has
signed
off
on
those
updates,
but
yeah.
So
the
first
one.
We
are
the
procedures
for
updating
and
renewing
key
materials
that
were
previously
missing.
We
add
the
type
to
the
key
distribution
request,
so
this
type
indicates
if
the
key
distribution
is
a
join
request.
H
So
when
the
job,
when
the
node
first
joins
the
group,
it's
a
leave
request.
If
it's
you
know
this
telling
the
dispersion
center
that
it's
actually
leaving
the
group
and
it
causes
rekeying.
For
the
current
group
members,
there
is
the
update
type
for
the
key
distribution,
which
is
the
node
requests,
the
most
the
most
updated
or
current
key
material
than
new.
C
H
I
H
H
H
J
H
It's
done
as
well,
so
other
updates.
We
have
added
additional
fields
for
negotiating
the
format
of
the
public
key
to
use,
so
this
is
done
in
the
201
response
to
token
post
in
the
ACE
exchange.
We
added
approval
to
session
signature
of
the
nonce
from
the
client
to
the
KP
distribution
center
in
the
key
distribution
request,
because
we
are
also
sending
this
public
key.
H
H
So,
following
the
some
reviews
of
version
o
2,
we
have
a
couple
of
open
points
we
would
like
to
discuss
today.
The
first
one
is
about
scope,
so
right
now,
scope
is
defined
in
this
document.
Is
the
finest
civil
array
of
two
elements
group
ID
in,
for
example,
multicast
or
a
topic
for
pops
up
and
then
one
or
an
array
of
roles,
so
you
can
see
in
the
example.
In
our
case,
we
have
array,
topic,
1
and
then
array
of
publishes
subscriber
MQTT
define
something
similar
in
a
different
format.
H
So
it
allows
for
multiple
scopes
and
multiple
roles
and
we
got
the
question
from
Jim.
That
was
sure
we
allow
multiple
scopes
in
the
same
access.
Token
ask,
for
example,
MQTT
does
and
to
answer
this
question,
we
have
to
look
at
the
actual
application
profiles.
For
example,
if
you
are
talking
about
multicast
and
multicast
using
oscar
group
comm,
then
no,
because
there
is
a
one-to-one
mapping
between
the
scope
and
the
security
group.
If
we
talk
about
pub/sub,
then
yes,
he
can
make
sense,
because
you
may
want
to
use
the
same
security
material
for
different
topics.
H
H
Also
Jim
note
is
that
there
is
no
need
for
sending
the
request
right
now.
The
case
is
key.
Distribution
request
was
sent
to
your
I
associated
to
the
topic,
so
since
the
topic
is
contained
in
the
access
token,
that
is
not
needed
or
sorry
in
the
in
the
institutional
requests
that
is
not
needed,
and
instead,
this
key
distribution
request
can
be
sent
to
a
fixed
group
URI
rather
than
one
associated
with
the
scope,
and
the
scope
can
be
made
mandatory
in
the
key
distribution
requests.
H
So,
for
example,
in
here
in
the
in
the
figure,
you
would
see
that
this
this
key
distribution
request,
is
sent
to
this
path.
Group
key
and
then
under
the
group
key.
There
is
a
resource
handler
that
is
going
to
redirect,
because
you
should
request
to
the
right
topic,
depending
on
the
scope
contained
in
the
message.
H
K
K
H
There
are
some
things
that
need
need
to
be
specific
to
the
tude
of
documents.
For
example,
the
values
of
roles
here
for
pops
up
would
be
publisher
will
be
a
texturing
with
publisher
and
subscriber,
but
it
can
be
the
same
in
both.
There
is
really
no
reason
to
have
it
different,
like
the
format
of
the
scope
can
be
the
same.
Do
you
see
a
reason
not
to
have
it
I
think
it
would
be
easier
actually
to
have
the
same
format.
E
K
H
H
Okay,
well,
let's,
let's
continue
some
more
open
points
so
right
now
the
the
document
specified.
It's
see
signs
and
ons
nan
Swan,
that
is
generated
by
the
KDC
for
pop
and
pub
key
and
Jim
suggested
that
we
add
second
nonce
nonce
to
that
is
signed
together.
We
don't
Swan
and
sent
to
the
KDC
distribution
requests.
It
seems
like
good
good
proposal,
so
we
would
go
ahead
and
implement
that
unless
they're
comments.
H
I'm
not
the
open
point,
and
we
would
like
the
opinion
of
the
earth.
Experts
here
is
about
registering
new
parameters,
because
right
now
we
have
two
new
parameters
that
we
are,
that
we
are
using
in
the
token
post
post
and
in
the
response
to
the
token
post
and
right
now,
we're
which
is
during
in
D
ace,
AS
creation,
hints
registry,
which
is
we
were
told,
the
wrong
place
to
do
it
and
Jim
suggested
that
we
registered
them
in
the
post
parameters
registry.
And
then
we
rd
both
parameters,
seaboard
mappings,.
H
H
H
H
Then
we
have
a
couple
more
points
that
are
about
rekeying.
So
what
the
document
says
about
Ricky
is
that
so
this
goes
back
to
the
discussion
we're
having
before
about
updating,
etc
Ricky.
So
the
KDC
should
renew
the
king
material
upon
group
membership
change
and
should
provided
to
the
current
group
members
through
drinking
scheme
use
in
the
group.
So
right
now
we
define
how
the
si
can
get
a
new
king
material,
and
we
say,
alternatively,
the
redistribution
King
material
can
be
initiated
by
the
KDC.
H
Otherwise
the
default
mechanism
will
be.
The
client
sends
a
request
to
the
KDC
asking
for
a
new
king
material
when,
if,
if
the
redistribution
key
material
is
initiated
by
the
KDC,
we
don't
know
what
end
point
should
the
KDC
use
to
send
Ricky
messages?
And
we
don't
know
if
this
is
in
scope
of
this
document,
but
we
think
it
should
be,
and
our
proposal
to
solve
this
is
to
define
a
new
optional
parameter,
called
reeking
URI
or
something
else.
H
If
you
have
that
idea
in
the
key
distribution
requests
and
the
client
used
this
parameter
to
tell
the
KDC
what
you
are
I
introduced
for
sending
unicast
request
messages
back
to
the
client.
So
in
this,
in
this
case,
the
client
would
take
the
role
of
the
server
and
is
telling
the
KDC
that
would
take
the
role
of
the
client.
F
H
G
H
H
H
H
Okay,
so
second
point:
another
alternative
mention
for
a
king
is
with
multicast
messages,
and
the
client
would
not
know
what
IP
multicast
address
he
needs
to
listen
to
for
a
keying.
So
the
proposal
is
to
define
a
new
optional
parameter,
breaking
your
eye
in
the
key
distribution
response
and
the
client.
It's
that
there
should
be
the
DC
uses.
This
parameter
to
listen
for
reading
messages
or
the
client
uses
this
parameter
to
listen
for
aching
messages,
but
if
the
KDC
that
sends
it
so
I
think
we
will
go
ahead
and
implement
this
proposal.
E
H
So
there
are
these
three
documents:
the
one
I
just
present
in
the
a
ski
group,
calm
and
then
there
are
two
additional
documents:
the
coop
pub/sub
profile
at
the
a
ski
group
home
or
score
and
the
profile-
and
we
get
this
question.
How
is
this
document
different
from
the
a
ski
group?
Calm?
It
looks
like
duplicated
text
and
I,
don't
see
what
it
adds
so
now
I'm
trying
to
answer
the
question.
H
Basically,
the
a
ski
group
on
the
one
I
just
presented
defines
a
general
message:
format,
fertilizing
and
providing
keys
to
group
members
in
the
context
of
group
communication.
It
does
not
specify
for
what
communication
transport
protocol
or
what
security
is
used
with
this,
the
a
score
pops,
a
profile,
define
specific
content
of
a
ski,
become
two
profile
to
use
it
with
coop,
pub/sub
and
cozy.
K
H
Bit
embarrassing,
why
are
these
separated
like
this,
because
when
I
first
came
came
here
with
the
coop
pub/sub
profile
and
that
contained
everything
in
one
document
and
then
I
was
told
await?
This
is
a
group
communication
profile
and
you
can
reduce
this
with
Oscar
communication
and
with
and
with
co-op
group
communication
and
I
said.
Okay.
Let's
do
that
then
I
split
that
up
and
I
said
you
can
reuse
this
with
group
communication,
but
you
need
to
structure
it
differently.
So
I
can
only
do
one.
H
We
need
to
decide
if
you
want
to
do
one
document
with
all
the
profiles
or
we
want
to
do
several
with
a
more
structure
in
a
different
way.
So
like
this
is
the
idea
base
because
of
a
comment
from
the
working
group.
Then
we
can
improve
for
sure
on
duplicate
text.
Hopefully
we
can
improve
on
not
repeating
text
and
making
it
clear,
but
we
need
to
decide
on
interaction,
so
I
I
think.
C
H
J
Rice,
an
update
on
this
application
profile
is
a
special
instantiation
of
the
drug
Francesca
just
presented
this
version
to
also
work
king
group
document
quick
recap,
but
you
should
be
familiar
with
the
main
model
right
now.
This
is
about
authorizing
nodes
to
join
a
group
where
communication
is
secured
using
group
post
call
and
through
the
joint
process,
getting
the
key
material
necessary
to
communicate
in
the
group.
So,
as
a
first
step,
a
client
asks
for
an
access
token
to
the
AES.
J
The
token
is
posted
to
the
group
manager,
which
is
the
KDC
of
the
general
model
and
in
the
response
it
gets
back
the
key
material
and
then
can
use
group
of
scores
to
talk
to
the
other
group
members.
What
is
out
of
scope
of
this
document
is
authorization
for
the
client
to
access
resources
at
the
very
group
members,
hint,
that's
the
next
presentation
and
the
actual
secure
communication
in
the
group.
Well,
that's
just
group
who
score
a
few
updates
from
previous
version,
mostly
based
under
here.
J
Most
of
the
things
are
aligned,
of
course,
to
the
corresponding
updates
on
key
group
home
that
Francesca
presented
so
some
renaming
of
rosin
profile,
name,
the
use
of
data
structures,
essentially
to
negotiate
parameters
on
signature,
algorithms
and
such
between
the
joining
node
and
the
group
manager
improve
text
about
provisioning
of
public
keys
from
the
joining
nodes
and
the
concede,
and
she
checks
that
the
group
manager
has
to
perform
on
them.
Also
considering
the
case
one.
Possibly,
the
group
manager
already
has
from
previous
interactions
with
the
joining
node
its
public
key.
J
We
also
extended
the
negotiation
on
these
public
key
related
parameters,
and
you
have
fundamentally
two
approaches
to
do
that
at
least
really
embeddable
in
two
ways,
so
that
can
happen
during
the
talking
post
and
response
or
during
the
joint
request
and
response.
So
it's
more
as
for
information
versus
try
on
veil,
also
included
the
proof
of
possession
of
the
clients
private
key
that
we
have
to
slightly
improve
on
just
a
mention
and
n
dimension
in
a
following
slide.
We
have
a
few
open
points
on
these
things,
speaking,
which
I
mentioned
already
approach.
J
G
J
The
second
point
there
was
a
new
registry
also
define
a
key
comb
actually
and
in
this
document.
Instead,
we
are
registering
a
value
in
it
specifying
that
public
is
in.
The
group
are
supposed
to
be
encoded
as
Kazuki's
and
right
now
we
don't
actually
have
any
particular
plan
to
register
any
other
encoding
that
we
cannot
even
think
about,
but
still
in
principle,
it's
good
to
keep
the
way
open
for
possible
future
and
codings.
Why
not?
But
then
the
point
is,
would
be
a
good
registration
policy
to
already
suggest
for
the
future.
Here.
H
J
Okay
for
the
proof
of
possession
of
the
clients
private
key
during
the
joint
request/response
exchange,
it
works
pretty
much
as
it
was
extended
in
Francesca's
comment
on
this
key
grow,
calm,
of
course
here
also
to
avoid
in
Oracle.
We
are
about
to
sign
both
dances.
One
one
got
back
from
the
resource
server
one
generated
by
the
client.
We
just
don't
think,
there's
really
nothing
else
to
sign.
In
addition
to
this,
we
don't
need
to
bring
in
anything
more
here
and
final
check,
so
we'll
keep
this
perfectly
aligned
with
it.
Keep
your
comments
in
this
ends.
J
J
In
case
this
happens
upon
many
nos
leaving,
but
probably
it
makes
sense
to
consider
an
alternative
or
a
rephrasing
so
that
the
group
manager
instead
must
or
should
preserve
the
very
center
IDs
for
all
group
members
upon
a
full
group
working,
and
this
is
different
from
a
corner
case
when
the
goal
of
the
group
manager
is
about
tricking,
a
single
group
member,
for
instance-
and
that
can
be
done
by
assigning
a
new
center
ID.
Exactly
to
that
group.
Member
only.
F
J
Okay,
so
this
is
for
the
corner
case
at
the
bottom
of
this
slide,
I
suppose,
example,
if
you
have
a
single
group
member,
whose
sender
sequence
number
ops
round,
it
has
been
formed,
the
group
manager
for
sure,
and
then
the
group
manager
has
two
choices.
First,
Ricci
the
whole
group
distributing
a
new
master
secret
altogether,
and
that,
of
course,
has
a
big
impact
on
performance.
J
There
is
a
shortcut
just
as
secure
for
the
European
answer
to
justice,
ein
the
new
sender,
ID
that
not
only
that
no
derive
out
of
that
a
new
sender
key
and
can
resume
communicating
with
sender
sequence
number
used,
especially
we're
starting
from
zero.
Of
course,
the
other
group
members
would
have
to
derive
a
new
recipient
context
out
of
that.
But,
overall,
the
the
reckoning
process,
especially
on
the
wire,
is
more
efficient,
but
this
is
the
particular
case
for
an
individual
node
to
rekey,
for
instance,
for
the
sake
of
rope
around.
J
Ok,
feedback
on
the
implementation
side.
We
are
continuing
on
that.
The
rise
implementation
covering
the
previous
version
of
all
the
drafts,
so
essentially
the
basic
functionalities
of
this
profile,
and
we
have
working
progress
on
aligning
implementation
of
this
latest
version
plus
admitting
more
than
one
transport
profiles.
So
we
start
with
with
the
details
profile
where
align
that
also
to
work
when
the
oscar
profile
is
used
between
the
joining
node
and
the
group
manager.
J
So
the
summary,
of
course,
as
predictable,
most
of
the
updates
were
related
to
keep
in
this
align
to
kiku
come
defining
some
more
details
typical
to
this
application
profile.
We
have
a
number
of
open
points.
Some
need
more
thought.
Some
are
pretty
clear
among
next
steps.
We'll
do
our
best
to
simplify
shorter.
The
document
be
to
avoid
repetition
from
a
comb
will
have
to
process.
The
latest
review
from
ludwig
step
by
step.
J
Why
did
we
start
this?
Well,
you
have
an
application
using
group
communication,
and
you
want
to
use
group
of
score
to
protect
the
message
exchange
in
the
group
as
I
quickly
mentioned
before.
Once
everyone
is
in
the
group,
would
you
do
about
access
control
to
access
resources
at
the
group
members?
Well,
some
use
cases
are
very
simple.
They
don't
really
need
any
anything,
particularly
difficult.
The
moment
you
have
been
authorized
to
become
a
member
of
the
security
group
and
you
got
the
key
material
in
those
use
cases.
J
That
can
be
not
fine
in
some
more
complicated
use
cases
where,
essentially,
you
want
to
differentiate
different
types
of
clients
that
are
allowed
to
do
different
things
of
different
resource
servers
in
the
group.
You
may
think
of
creating
additional
security
groups
as
you
need
this
risk
scale
very
poorly.
J
You
need
to
create
many
groups,
perhaps
essentially
one
for
each
subset
of
clients,
depending
on
the
access
rights
you
want
to
grant
them
so
instead
it
will
make
sense
to
think
of
using
ace
to
enforce
fine-grained
access
control
through
access
tokens
and
then,
if
you
consider
using
Hayes,
you
have
a
problem.
If
you
think
of
the
currently
available
transport
profiles
of
ace,
it's
not
possible
to
secure
group
communication
in
particular
in
particular,
using
group
of
score
and
every
currently
available
profile
is
considered
a
single
security
protocol.
J
Even
if
you
think
of
the
the
closest
possible
profile
we
can
think
about
the
oscar
profile
kind
pterosaur
service
was
to
use
an
Oscar
and
group
of
scholars,
just
not
admitted
so
bottom
line.
You
cannot
have
at
the
same
time
the
usage
of
group
of
score
and
an
access
control
of
resources
at
group
members
based
on
ace
and
the
reason
we
started.
This
document
is
exactly
to
fill
this
gap.
So
it's
a
new
transport
profile
base
group
pasquale
profile.
J
The
strongly
builds
on
the
score
profile
we're
using
a
lot
of
in
construction
of
its
constructions,
and
it
essentially
admits
to
security
protocols,
both
Oh
score
and
group
of
score
among
group
members
and
as
a
starting
point.
It
assumes
that
the
client
and
restore
server
using
this
profile
are
already
both
member
of
a
non
score
group
that
they
have
joined
in
a
band.
You
run
this
profile
and,
as
a
final
result,
you
get
a
pairwise
of
score
security
context
between
client
or
server
just
like
this
core
profile.
J
But
in
addition
here,
you
have
the
access
token
bound
not
only
to
the
pairwise
context,
but
also
to
the
group
of
score
security
context.
In
addition,
the
two
different
contexts
aisle
are
also
bound
to
each
other,
and
that's
because
we
are
deriving
the
pairwise
context
using
also
parameters
from
the
group
context.
J
Properties
are
the
one
typical
of
the
expectations
from
profiles
of
ace
plus.
Here
we
also
have
proof
of
group
membership
for
that
exact
client.
Posting.
The
token,
thanks
to
the
bond
between
the
token
and
a
group
context
to
give
an
overview
in
a
feasible
way
as
Delta's
from
the
oscar
profile.
First
step
the
client
contacts
the
authorization
server
asking
for
an
access
token.
As
usual,
it
specifies
two
additional
pieces
of
information.
J
J
Then
the
client
continues
posting
the
access,
token
others
or
server,
and
there
is
an
exchange
of
nonces
just
like
it
happens
with
the
oscar
profile.
If
the
token
is
valid,
there
is
our
server
stores
the
extras
talking
together
with
those
junior
additional
parameters
that
the
client
has
specified
and
that
were
included
in
the
access
token-
and
here
is
when
things
get
interested
for
someone
interested
in
the
extreme
details.
This
is
aligned
to
the
second
from
last
version
of
your
score
profile,
but
I
can
skip
that
now.
J
Client
or
server
have
to
derive
the
pairwise
Oscar
security
context
as
follows.
Essentially
they
need
to
prepare
three
parameters:
context
the
remaster
solve
the
master
secret
to
derive
the
context
about
the
context
ID
they
concatenate
the
to
nancy's,
plus
one
more
piece
of
information.
The
group
ID
of
the
oscar
group
that,
by
the
way
the
server
was
able
to
retrieve
also
from
the
access
token
for
the
master
solved
a
concatenate
two
pieces.
The
first
one
is
the
sender
ID
of
the
client
in
the
oscar
group.
J
That
was
also
included
in
the
master
in
the
access
token
for
the
resource
server
and,
if
any,
because
it
can
be
empty,
the
master
site
used
in
the
oscar
group
context
the
master
secret.
I
concatenate
two
pieces.
The
first
one
is
the
oscar
master
secret
indicated
in
the
access
token,
and
provided
also
to
the
client
as
an
s-parameter.
The
second
piece
of
information
is
the
master
secret
of
the
oscar
group
and
well.
Both
client
and
resource
know
that,
because
they
are
both.
Member
of
the
group.
K
J
K
A
bit
annoying,
maybe
because
possibly
want
to
specify
the
subset,
and
you
remain
that,
even
though
the
group
may
change
and
the
coop
member
changed.
So
if
you
could
just
make
the
first
part
of
the
group
it
there,
instead
of
the
whole
group,
it
I
think
that
would
be
more
stable.
If
one
group
changed
okay,.
J
J
Third
step
there
can
be,
for
instance,
first
unicast
requests
with
a
score
from
client
or
server,
and
you
can
see
here
the
context
that
is
consistently
extended,
and
then
you
have
a
multicast
request,
protected
with
record
from
C
to
the
group
and
both
resource
everyone.
Until
reply
to
the
client
now
for
versions,
you
don't
have
already
in
a
pin
point
out
of
a
very
good
discussion
we
had
with
Jim
during
the
a
curtain.
J
J
Essentially,
you
may
have
a
node
and
one
in
group
that
asks
for
an
access
token,
but
declaring
the
sender
ID
of
an
and
one
would
get
an
access
token
for
itself.
If
it's
authorized
to
you
can
post
it
to
the
resource
server,
but
then,
if
it
uses
all
the
unicast
no
score
since
no
strict
identity
and
not
no
confirmation
of
the
sender,
ID
event
is
involved.
The
the
consequences
of
dead
action
performed
legitimately
by
anyone
can
be
kind
of
shifted
to
n2.
J
So
the
way
out
for
this
is
involving
in
the
process
exactly
the
public
key
that
n1
uses
in
the
group.
This
can
be
provided
to
the
AES
upon
request
in
the
access
token,
and
when
doing
that
performing
proof
of
possession,
then
the
other
ization
server
can
include
that
public
key.
Also
in
the
access
token,
it
will
be
posted
on
the
resource
server.
That
can
then
store
the
access
token
paired,
also
together
with
that
public
key,
and
that
would
essentially
fix
that
problem.
So
we
plan
for
sure
this
update
in
the
next
version
of
the
document.
J
So,
as
a
final
summary,
this
is
a
new
transport
profile
of
Ace
to
admit
the
usage
of
Oscar
and
group
of
score
and
a
group
communication
scenario
where
you
need
some
fine-grained
access
control
on
the
group.
Members
resources
through
ace,
both
unicast
pairwise
and
group
context,
are
bound
with
each
other
and
the
access
token
is
bound
to
both
context
as
well,
and
we
are
relying
as
much
as
possible
to
a
score
and
these
constructions
just
do
not
have
an
insane
Delta
introduced
here.
Of
course,
Commons
reviews
are
welcome.
O
O
So
for
those
who
were
not
following
the
site,
discussion
on
jabber
I
think
there
are
a
number
of
ace
documents
and
one
or
two
core
documents
dealing
with
group
communication
security
now,
and
it
might
be
quite
helpful
for
someone
coming
to
one
of
these
groups
as
a
new
participant
to
have,
for
example,
a
wiki
page
or
an
informational
RFC.
That
explains
how
these
group
communication
documents
interlink.
O
H
So
I'm
back
today,
security
for
group
communication
in
ace
okay.
So
this
draft
is
about
co-op,
pub/sub
security,
community
security
using
ace
we're
at
version
5,
so
I
already
presented
this
slide
by
now.
I
hope
that
I
made
a
case
yeah.
We
can.
We
can
discuss
more
on
this,
but
hopefully
we
can
keep
with
the
current
structure
and
improve
the
text
so
that
it's
not
as
confusing
so
quick
recap
on
this
document.
This
document
defines
how
to
use
a
stew
with
rice
nodes
and
provision
keys
for
co-op
pub/sub.
H
The
goal
is
to
protect
co-op
pub/sub
communication
using
the
keys
provided.
This
RAF
was
first
submitted
at
IETF
98.
It
got
several
reviews
and
bodies,
positive
feedback,
and
it
was
then
updated
following
the
ACE
Group
comm
updates.
After
the
split
with
that
document,
there
is
related
work
that
is
going
on.
H
There
is
the
core
co-op
pub/sub
that
is
close
to
being
done
in
core,
and
then
there
is
the
mqtt
pub/sub
profile
vase
that
has
been
adopted
in
this
working
group
last
meeting,
I
believe
and
then
a
picture
to
show
the
members
or
participants
in
this
profile.
So
we
have
the
publisher,
subscriber
and
the
broker,
and
this
profile
aims
at
setting
and
security
association
between
the
publishers
and
the
broker
and
one
between
the
publisher
and
the
subscriber
optionally,
also
one
between
the
broker
and
a
subscriber,
and
it
uses
two
different
authorization
servers.
H
So
we
got
a
review
very
recently,
so
we're
planning
an
update
which
we
would
like
feedback
from
the
working
group
about.
So
this
comes
from
a
review
but
yeah.
So
the
first
request
was
to
generalize
the
exchange
and
split
split
the
authorisation
and
key
distribution
requests
which
are
now
merged
into
one
so
to
make
it
more
similar
to
a
ski
group
from
a
score
with
the
fool
first,
the
ACE
exchange
and
then
the
key
distribution
requests
and
response,
because
this
was
these,
two
requests
were
merged.
H
F
H
H
H
So
right
now
the
part
about
actually
securing
the
pub/sub
it's
only
using
cosy
and
with
keys
in
place
and
just
protecting
the
content.
The
publication
content.
So
now
we
can
make
this
better
by
using,
for
example,
replay
protection
mechanisms,
sequence
numbers
and
using
the
nonce
duration.
That
is,
you
know,
score.
H
H
H
H
So
the
next
steps
would
be
to
update
first,
then,
we
see
or
I
think
that
this
document
is
ready
for
adoption
and
I
would
like
to
get
it
adopted
as
soon
as
possible
so
that
it
can
be
moved
forward
with
the
MQTT,
pub/sub
and
mqtt
pub/sub
authors
we're
interested
in
this
because
they
were
interested
in
the
part
about
protection
of
the
publication
content.
So
maybe
we
can
reuse
that
and
synchronize
with
with
them
about
that
part.