►
From YouTube: IETF111-ACE-20210729-2200
Description
ACE meeting session at IETF111
2021/07/29 2200
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
A
A
A
Now,
assuming
those
drafts
are
going
to
be
done
and
sent
to
the
isg
soon,
we
have
a
another
bunch
of
draft
that
working
group
is
should
be
focused
on.
So
we
have
the
key
group
com
for
this
draft.
We
do
expect
to
have
a
working
group
last
call
to
start
right
after
this
etf
and
we're
basically
encouraging
people
to
review.
A
A
Yeah,
we
will
we'll
see
what
is
going
on,
maybe
the
the
not
the
right
button
of
impressed,
but
this
is
a
what
we
have
in
mind,
so
so
the
other
drafts,
so
the
the
draft
we
are
expecting.
Some
reviews
is
the
key
group
com.
So
what
I
would
like
to
check
is
who
is
volunteering
to
review
this
draft
in
the
next
few
weeks?.
A
A
A
E
E
I'm
I
am
checking
document
marco
has
taken
a
bit
of
the
the
editor
role
now
because
I
don't
have
time
to
to
drive
it,
but
I
I
I
have
been
following
the
the
document
and
the
update,
so
I
I
don't
know
how
valuable
my
review
is.
Like.
Obviously
I
as
an
author,
I
don't
know
that
it
makes
sense
for
me
to
I
mean
any
any
comment
I
have
will
be
implemented
in
the
document.
A
So,
okay,
as
you
wish,
I
I
think
it
would
be
useful,
though
that's
but
feel
free
to
do
right.
So
so
it
means
I'm
gonna
kick
off
the
the
working
group
last
code
next
week.
Then
then,
the
the
other
draft
in
the
in
the
queue
is
the
pub
sub
profile.
So
this
is
also
one
of
the
draft
we
do
have.
That
has
a
a
pretty
high
priority,
so
I
I
think
sig
dem
is
presenting
that
draft
very
soon.
A
And
I
think
that's
all
so
I
suggest
that
we
we
continue
to
have
those
interim
meetings
so
that
we
can
make
some
significant
progress
with
the
with
the
drafts,
and
the
other
thing
is
that
we
should.
We
are
one
working
group,
but
we
should
not.
We
should
also
consider
that
we
do
have
other
working
groups
like
oauth
and
the
app
or
I
don't
know
how
to
pronounce
that.
A
F
C
Thanks
for
giving
me
that
time,
so
I
just
wanted
to
sort
of
reiterate
the
thanks
to
all
the
authors
and
everyone
who
worked
on
the
core
cluster
of
documents.
It's
really
great
to
be
able
to
send
those
over
to
rfc
editor.
I
know
that
I
was
sort
of
part
of
the
delay
in
that
after
the
isg
review
had
finished
up
and
then
I
was
just
very
busy
with
one
thing
after
another
and
didn't
get
a
chance
to
do.
C
So
the
next
document
on
my
list
to
review
the
publication
requested
queue
is
actually
the
mqtt
profile.
So
I
expect
the
next
couple
weeks.
I
should
have
something
there
as
well,
so
thanks
again
and
it's
great
to
have
the
core
work
done,
and
we
of
course,
still
have
more
things
to
do
for
your
communication
and
whatnot
so
keep
busy
with
that
and
over
to
the
next
presentation.
I
guess.
G
Yes,
this
is
done
so
hey.
Thank
you
very
much
er
for
starting.
I
would
like
to
thank
mohit,
seti
and
karsten
for
their
review
on
the
previous
version
that
we
used
to
improve
and
based
on
their
reviews.
We
are
presenting
now
the
last
version
of
the
document
so
based
on
their
feedback.
We
added
a
well-known
uris
for
both
entities,
as
the
exchange
has
both
of
them
at
one
point
as
a
server.
G
G
G
So,
since
the
iot
device
will
always
start
with
the
first
message
as
a
client,
we
need
to
have
this
well-known
uri,
also
in
the
controller
that
is
only
for
this
first
exchange
and
in
the
for
the
rest
of
the
exchange.
The
iot
device
is
the
co-op
server,
but
for
the
message
number
two,
we
also
need
to
have
this
well-known
uri
active
after
that
the
workings
of
the
I
it
was
a
scheme
to
keep
the
ordering
warranty.
It
comes
into
place
that
is
in
the
next
slide.
A
D
A
D
G
G
G
G
Regarding
the
well-known
uri,
because
that
resource
is
going
to
be
available
always
so,
the
thing
is
that
when
this
message
comes
from
the
hip
authenticator
from
the
controller
to
the
peer
during
an
ongoing
authentication
because
it
got
delayed
or
wherever
what
the
iot
device
the
web
server
will
do
is
understand
that
we
are
in
the
middle
of
an
ongoing
authentication
and
as
a
signaling,
that
it
is
not
in
its
position
to
attend
to
that
message.
It
would
just
send
a
reset
message
to.
G
G
E
G
E
G
During
the
a
that
the
authentication
has
finished,
then
there
is
the
controller,
doesn't
have
any
additional
knowledge
about
being
a
message
out
of
place
and
it
will
start
a
normal
authentication
process,
but
because
the
iot
device
was
not
the
one
that
started
the
process,
it
will
also
send
a
recent
message,
letting
him
know
that.
Okay,
I
need
to
be
the
one
that
starts
the
the
process
with
the
first
post,
sent
by
by
me
right
in
the
next.
G
We
had
two
options
basically
to
create
a
new
option
specifically
for
this
purpose,
but
we
decided
that
this
was
not
the
best
alternative,
because
we
were
forcing
all
co-op
implementations
to
be
updated.
I
think
that's
not
desirable
and
the
other
option
was
embedding
the
services
negotiation
inside
the
payload.
G
The
the
problem
is
not
a
problem,
but
the
issue
is
that
currently
we
are
carrying
the
ip
messages
inside
the
payload,
so
we
need
just
to
be
aware
of
the
structure
of
the
message
to
be
able
to
parse
it
correctly
and
but
in
addition,
we
also
need
to
be
aware
of
that.
We
need
to
prevent
a
downgrading
downgrading
attack,
so
in
the
next
slide
we
explain
how
we
understand
that
this
could
be
done
so
with
the
quad
payload.
G
Next
slide.
Please
here
are
the
key
derivation
process
for
establishing
the
oscore
security
context.
We
are
deriving
the
master
secret,
this
master
result
and
also
the
recipient
id
and
the
sender
id
all
based
on
the
msk.
We
are
using
in
the
master
secret
and
master
assault
what
we
call
their
cso.
That
is
the
contents
of
the
cypher
suite
negotiation.
G
This
way
we
are
binding,
the
the
content
that
was
exchanged.
So
if
a
downgrading
attack
is
performed,
the
derivative,
the
derived
keys,
will
not
match
and
the
context
will
not
be
the
same.
Hence
the
oscar
negotiation
will
not
be
successful.
We
are
setting
the
length
to
the
maximum
specification
of
the
os
core.
G
Rfc
so,
for
instance,
the
recipient
id
and
the
sender
id
have
a
maximum
length,
depending
on
the
degree
chosen.
We
are
specifying
in
length
that
we
we
will
use
the
maximum
length
allowed
the
next
slide.
Please
there
we
can
see
there
the
the
complete
exchange
in
the
current
state,
so
there
we
can
see
how
we
are
basically
using
the
the
well-known
uri.
In
this
case
we
are
concatenating
their
the
character
switch
in
the
second
and
third
message
and
additionally,
we
are
adding
in
the
message
number
nine,
along
with
the
ip
success,
some
authorization
information.
G
G
G
E
E
D
Thank
you,
yeah.
I
have
a
pretty
simple
observation,
so
you
are
designing
a
few
new
protocol
data
units
here,
like
the
set
of
cipher,
suites
and
so
on,
and
just
make
sure
that
you
design
them
in
such
a
way
that
when
you
have
to
have
the
second
version
of
this
protocol,
you
have
an
ability
to
extend
this.
So
you
have
something
in
the
array
or
in
the
session
lifetime
that
allows
you
to
up
a
counter
and
say
something
different.
C
And
in
particular
we
had
to
change
the
dtls103
spec
after
isg
evaluation.
In
order
to
add
that
particular
indication
of
success-
and
it
looked
like
on
the
lighter
diagram
that
you
had-
that
the
actual
success
itself
would
be
conveyed
inside
the
inner
payload
of
a
os
core
option
which
seems
to
me
like
it
would
count
as
a
protected
indication
of
success.
H
A
A
I
The
document
initially
focused
on
how
to
authorize
pub
sub
clients
using
the
ace
framework,
in
the
sense
that
authorizing
clients
to
the
broker,
as
well
as
protecting
the
message
content
from
the
broker
so
establishing
a
security
association
between
publishers
and
subscribers,
focusing
particularly
on
co-app
and
in
parallel.
We
had
mq2tls
profile,
which
basically
looks
at
token
transport
and
pops
up
client
authorization,
but
it
didn't
cover
the
message
protection.
So
we
looked
at
how
we
can
contribute
the
mqtt
description
to
the
to
this
profile
too.
I
I
So
let
me
remind
you
what
that
change
was
formerly
we
had
in
the
architecture.
Two
authorization
servers,
one
set
up
the
security
context
between
the
publisher
and
the
broker
and
the
other
one
was
used
to
create
a
security
context
between
publisher
and
subscriber,
so
they
can
protect
their
communication
from
the
broker.
I
We
basically
relied
on
the
group
com
description
while
looking
at
this
and
trying
to
understand
how
we
could
map
to
mqtt
and
some
of
the
concerns
raised
previously
by
the
separation
of
asses,
especially
when
the
consistency
of
the
policies
that
they
have
to
work
with
might
be
a
problem.
We
decided
a
new
architecture
where
we
have
now
a
single
authorization
server
and
a
key
distribution
center
and
the
broker
are
effectively
acting
as
resource
servers
for
this
authorization
server.
I
Now
one
for
an
implementer
can
decide
to
separate
this
to
two
separate
asses,
but
then
the
policy
synchronization,
like
the
decisions
that
are
used
to
make
to
grant
tokens
to
the
publisher,
subscriber
clients
and
their
consistency
is
implemented
as
a
choice,
not
as
something
by
default
that
needs
to
be
handled
by
the
implementer.
So
that's
what
we're
achieving
by
this
single.
As
with
this,
we
basically
also
change
the
authorization
request
a
little
bit
before.
There
has
to
be
two,
of
course,
authorization
requests,
respectively
to
the
two
separate
authorization
servers.
E
I
And
the
broker
and
the
same
token
can
be
used
to
establish
a
secure.
You
know
connection
between
the
kdc,
the
broker
and
you
know,
make
sure
that's
the
pub
sub
clients
are
authorized
to
the
broker,
as
well
as
used
to
retrieve
the
key
material
from
the
kdc
to
protect
their
communication,
while
they're
sending
messages
through
the
broker.
I
And
another
thing
that
we
achieved
with
this
is
that
now
previously
there
was
a
distinction
between
publisher
and
subscriber
clients
and
publisher.
Clients
were
expected
to
be
authorized
to
the
broker
and
subscriber
clients
were
not
because
they
need
to
get
the
right
keys
from
the
kdc
to
be
able
to
read
the
subscription.
You
know
the
publications,
so
it
wasn't
found
essential
to
authorize
them
to
the
broker.
I
However,
while
this
might
be
an
overkill
for
some
applications,
we
kind
of
chose
to
support
the
subscriber
authorization
by
default
and
bypass
it
if
it's
not
necessary
and
allow
subscribers
to
connect
with
that
authorization
to
the
broker.
If
the
broker
allows
it.
But
that's
left
as
an
option,
and
it's
not
just.
I
I
A
the
the
token
yes,
so
the
the
secret
that
is
needs
to
be
used
for
to
be
able
to
establish
the
secure
connection.
Yes,
so
that
is
a
single
thing,
and
that
might
be
something
that
needs
to
be
discussed.
But
we
thought,
since
is
the
same
set
of
policies
that
needs
to
be
consulted
to
grant
a
permission
to
the
publisher,
subscriber
client,
one
for
to
be
able
to
publish
or
subscribe
to
a
topic
and
then
to
be
able
to
encrypt
or
decrypt
what
is
published
to
that
particular
topic.
I
I
Okay,
but
this
is
a
good
point,
and
this
is
something
that
we
would
be
very
happy
to
receive
comments.
We
were
discussing
with
francesca
about
this
change
as
well,
because
this
is
a
this
is
one
of
the
main
changes
that
we've
introduced
as
well
going
to
two
audiences
in
a
single
token,
and
if
there
are
any
concerns
that
are
found
by
the
working
group
about
this,
we're
very
happy
to
hear
and
reconsider
that
decision
next
slide.
I
Okay,
so
I
just
wanted
to
show
how
the
protocol
flows-
and
you
know
focusing
on
choir,
but
it's
very
similar
to
the
mqtt
case
as
well,
where
the
client
will
be
requesting
authorization
from
the
authorization
server
get
a
token.
You
know
in
response.
It
will
use
that
to
establish
a
secure
connection
to
the
kvc,
send
a
join
request
to
the
kdc
here.
The
join
request
is
to
a
group
and
which
is
representative
of
a
topic
that
the
client
is
trying
to
publish.
I
So
we
kind
of
have
an
equivalence
between
topics
and
security
groups
here
and
then
the
client
uses
the
same
token
to
establish
a
secure
connection
to
the
broker
and
typical
pops
up
operations
with
protected
payloads,
using
these
keys
retrieved
from
the
kdc.
The
change.
As
I
said,
there
is
no
joint
authorization
and
join
request
to
the
as2.
They
are
now
separated
and
there
are
two
separate
requests
now:
an
authorization
request
to
the
as
and
a
join
request
to
the
kdc
next
slide,
mqtt
specific
consideration.
I
So
there
must
be
a
way
for
the
clients
to
identify
or
map
their
application
topics,
application
groups
to
their
security
groups.
They
have
to
discover
that
association
and
in
mqtt
a
typical
prefix
used
to
publish
that
type
of
information
is
the
dollar
sys
topic
and
that
can
be
used
to
publish
broker
specific
information.
It's
very
widely
adopted
a
very
well-known
also
it's
represent.
You
know
it
is
acknowledged
in
the
mqtt
specification
as
well,
so
this
can
be
used
to
publish
this
kind
of
associations
next
slide.
I
But
we
are
also
acknowledged
that
it
introduces
another
step,
because
you
have
to
authorize
to
the
as
to
be
able
to
public.
You
subscribe
to
the
cis
topic
and
then
learn
the
mappings.
Then
go
back
to
the
ais.
Get
you
know
your
token
upgraded
to
cover
the
additional
groups
that
you
want
to.
You
want
to
communicate
to
and
then
come
back
and
retrieve
the
keys
and
etc
so
that
it
requires
a
kind
of
an
another
step
to
be
able
to
get
the
token
the
once
the
client
gets
the
necessary
mappings.
I
The
token
request
will
have
scopes
covering
each
security
group
and
then
the
kdc
will
be
receiving
separate
joint
requests
for
each
of
the
security
groups
that
the
client
needs
to
be
a
part
of
now.
Of
course,
the
publications
will
be
protected
with
the
corresponding
key
for
the
security
group,
and
then
the
rs
would
validate
whether
that
mapping
is
correct
and
it's
represented
in
the
token
for
the
client.
I
For
the
subscribe
case
again,
you
can
subscribe
to
filters,
but
we
put
the
onus
on
the
on
the
client
to
be
able
to
separate
those
topics
so
that
it
mat
it's
kind
of
maps
to
a
single
security
group
so
that
the
broker
can
reject
a
subscription
request
directly
and
not
necessarily
need
to
do
computations
about.
You
know
how
much
of
that
topic
is
covered
in
that
particular
security
group,
so
whatever
filter
you're
requesting
it
must
belong
to
a
single
security
group.
So
those
are
the
considerations.
I
We've
added
we've
kind
of
put
the
work
on
the
client
to
ask
for
the
right
things
so,
but
I
think
it's
kind
of
a
good
trade-off
at
the
moment
to
handle
the
topic
filters
that
have
white
cards
and
last
slide.
Please
next
slide,
and
that
will
be
my
last
slide.
So
I
think
the
the
draft
is
ready
at
the
moment
to
be.
You
know
with
its
final
descriptions.
I
C
Yes,
you
know
the
that
I
don't
think
it's
inherently
flawed
and
that
we
should
look
at
it
carefully,
but
I
think
there
are
some
situations
where
it
will
make
sense,
but
the
security
properties
of
how
that
works
do
vary.
Quite
a
bit
depend
on
what
type
of
possession
key
you're
using
in
the
token
like,
if
you're,
using
a
symmetric
proof
of
possession
key
that
sort
of
intrinsically
is
falling
into
the
cases
that
we
just
recommend
in
the
core
framework.
C
I
I
think
yes
you're
right.
I
think
we
have
to
describe
it
for
both
cases
and
the
ace
typically
falls
back
to
symmetric
proof
of
possession
keys
so
in
the
in
the
main
framework.
So
maybe
describing
it
for
both
cases
and
giving
it
as
an
option
might
be
a
better
thing.
Or
do
you
suggest
to
go
to
two
tokens
by
default
and
then
describe
don't
even
bother
describing
to
audiences.
C
I
mean
I
think,
that
you're
you're
correct
that
there
is
enough
overlap
that
it
will
be
very.
It
will
feel
natural
in
many
cases
to
use
the
single
token.
So
I
do
not
propose
to
make
the
default
v2
tokens.
Okay,
but
yeah.
We
probably
will
need
to
have
separate
treatment
for
the
symmetric
versus
asymmetric
case.
I
A
J
J
A
A
A
F
Right,
hi,
everyone
so
yeah
before
getting
into
the
draft.
I
was
asked
by
the
chairs
to
give
an
overview
of
the
group
con
documents
in
ace
how
they
relate
to
each
other
and
starting
from
the
left.
You
see
in
fact
giggle
com.
It
provides
general
message,
formats,
procedures
and
an
api
for
a
key
distribution
center
to
distribute
key
material
to
use
for
group
communication.
F
But
then
you
need
to
have
instances
practical
instances
as
application
profiles
of
this
document,
and
we
have
two
at
the
moment.
One
is
the
pub
sub
profile
just
presented
by
sigm
and
the
other
one
is
a
keygroup
com,
oscor
that
rather
than
pub
sub,
it
considers
group
communication
for
co-op
protected
with
group
score
as
security
protocol,
and
it
essentially
extends
the
api
at
the
kdc,
which
is
specifically
an
escort
group
manager
for
joining
nodes
and
group
members.
F
F
Thank
you,
so
I
anticipated
that
at
an
interim
we
had
in
june,
the
group
of
score
documenting
core
was
undergoing
some
major
updates
that
had
an
impact
for
short
on
key
group
common
score,
but
some
things
were
so
general
that
were
actually
better
to
be
done
in
this
document,
as
in
principle
relatable
to
all
possible
profiles
of
it.
But
at
the
end
of
the
day,
it
was
only
about
three
things
and
number
one.
We
generalized
the
proof
of
possession
of
the
joining
notes,
private
key.
We
were
going
just
for
a
signature.
F
F
As
a
second
point-
and
this
is
also
an
alignment
with
group
of
score
with
what
is
going
on
in
the
lake
working
group
with
edoc-
we
are
still
indicating
the
format
of
public
keys
used
in
the
group
with
the
pacquiao
parameter,
but
before
we
were
sticking
to
a
role
playing
a
cozy
keys.
Essentially
it
was
simpler.
F
We,
we
are
not
assuming
anymore,
that
the
format
of
the
public
in
the
group
is
also
embedding
the
identifier
of
the
corresponding
node
of
the
group
member
corresponding
to
that
public
key,
and
this
is
something
actually
that
at
some
point,
ben
was
hoping
we
we
could
consider
and
taking
the
this
alternative
route.
We
ended
up
there
anyway.
So
now
we
are
just
using
a
separate
parameter
that
we
had
around
all
the
time
anyway,
as
optional
to
be
used
peer
identifiers.
F
A
F
Thank
you,
watson.
The
general
case
is
that
at
any
point
in
time
a
group
member
doesn't
know
of
what
other
group
members
are
there.
That's
something
they
can
learn
query
in
the
kdc
for
the
current
public
keys
in
the
group.
More
specific
security
considerations
should
come
in
the
application
profiles.
That
instance,
this
document.
F
B
A
B
B
Sorry
about
the
audio
drop
okay,
I
I
am
de-confused.
This
is
just
about
sort
of
group
membership
you're,
just
getting
handed
saying
that
indicates
that
you're,
a
member
of
the
group
and
and
okay-
and
so
that's
fine,
maybe
there's
some
text
in
the
draft
that
I
overlooked,
or
maybe
you're
saying
that
should
be
edited
to
make
it
clearer
I'll.
Take
a
look,
but
thank
you
very
much
for
clearing
that
up.
Thank
you.
Watson.
A
A
A
F
Yeah,
so
there's
definitely
no
time
to
go
through
the
details
update,
but
basically
there
were
changes
in
the
grupo
score
document
in
core,
and
the
update
to
this
document
was
about
aligning
it
to
the
group
of
score
drafting
core
and
especially
additional
requirements
and
expectations
of
services
that
the
group
manager
had
to
provide.
In
that
case,
that
involved
parameters,
proof
of
possession
for
the
different
modes
supported
in
the
group
and
much
stricter
policies
for
re-keying
the
group
and
keeping
the
security
properties
of
group
score
fulfilled.