►
From YouTube: IETF112-ACE-20211109-1430
Description
ACE meeting session at IETF112
2021/11/09 1430
https://datatracker.ietf.org/meeting/112/proceedings/
B
B
You
have
the
nut.
Well
in
case
you've,
never
read
those
or
you
were
not
aware
of
those
noteworld
meetings.
So
please
have
a
look
to
do
that
and
we're
looking
for
a
minute
texture.
So
we
already
have
christian,
but
if
anyone
else
is
willing
to
help
him
it's
more
than
welcome.
So
do
we
have
a
second
minute
taker.
B
Yeah
I
can
help
okay,
thank
you
garan.
I
guess
it's
goran,
so
just
be
informed
that
we
have
a
new
code
of
conduct
at
the
itf.
I
don't
think
we
ever
had
any
problems
in
this
working
group
before,
but
I
mean
we
need
to
to
to
make
the
the
conversation
professional
and
it's
a
quite
a
quite
standard
behavior.
B
The
goal
of
this
meeting
is
clearly
to
end
up
every
document
that
we
have
in
working
group
last
goal
or
that
are
going
to
be
in
the
working
group
last
goal
in
a
few
days.
So
that's
the
priority
for
the
the
first
priority
for
that
meeting.
The
second
priority
is
about
adapting
new
work
and
to
have
those
discussions
and
that's
it
so
where
we
are
with
this
working
group,
we
actually
have
one
two
three
four
five
documents.
So
it's
go
up
east
waiting
for
dtls.
B
B
B
One
comment
I'd
like
to
say,
and
mostly
to
make
it
very
clear
to
everyone-
is
that
the
the
cmp
v2
draft
needs
to
progress
through
the
rfc
editor
in
parallel
with
some
other
documents
in
lamps,
mostly
because
they
are,
they
have
a.
They
do
share
a
registry
at
the
ayana.
So
that's
one
of
the
reason
yeah
so
and
we
do
have
two
documents
in
working
group
last
goal.
B
So
that's
the
key
group
comms
and
the
co-op
eep
and
a
few
other
working
group
documents
among
those
the
key
group
combo
score
that
is
going
to
be
moved
in
working
group
last
goal.
Hopefully
in
the
few
next
days.
That
said,
I'm
just
wondering
if
ben
or
adi
is
willing
to
add
anything
if
he
has
any
question
or
if
anyone
has
any
comments
to
say
to
our
80.
So
please.
B
A
F
E
E
We
leave
it
out
of
the
scope,
but
we
added
some
discussion
of
how
can
this
be
done?
We
understand
that
co-op
brings
some
tools
to
the
table
for
a
resource
disco
discovery
and
we
are
using
that
as
part
of
co-op,
but
in
terms
of
getting
the
information
of
the
ipv6
of
the
border
router
or
the
entity
in
the
domain
with
which
the
ip
authenticator
is
going
to
talk
to.
We
leave
that
out
of
the
scope,
but
there
are
different
approaches
that
could
be
considered
depending
on
the
deployment
scenario
such
as
dhcp
or
multicast
dns.
E
F
E
The
ip
message
we
send
in
a
silver
structure,
the
crypto
street
negotiation,
the
values
of
the
christian
scriptures
with
negotiation,
and
we
also
send
in
the
request
and
response
the
sender,
id
and
response
id
for
oscor.
This
is
this:
can
all
this
can
also
be
reused
as
key
id
for
the
tls?
As
we
will
comment
in
the
last.
E
E
So
we
maintain
the
use
of
oscor
in
this
case,
in
the
basic
exchange
as
a
way
of
confirming
that
the
key
material
derived
from
the
hip
authentication
is
established
correctly
and
we
double
down
on
on
the
use
of
a
score
by
establishing
the
oscars
security
association
that
could
be
used
from
that
point
on
to
secure
any
exchange
between
the
iot
device
and
the
controller
to
do
so.
What
what
we
propose
and
also
think
I
I
want
to
take
a
second
to
thank
christian
answers
for
his
input
on
this.
E
We
create
a
a
a
template,
an
incomplete
oscore
security
context
that
is
missing.
The
key
which
is
completed
after
the
authentication
is,
is
completed,
and
what
we
do
is
that,
upon
reception
of
the
if
success,
what
we
do
is
to
complete
the
oscar
security
context
and
be
able
to
complete
the
key
confirmation.
E
The
the
detail
here
is
that,
basically,
we
generally
generate
the
the
the
needed
context,
but
we
need
to
use
the
oscar
message,
the
first
task
or
message
as
a
alternate
success,
indication
for
ip,
because
the
content
is
ciphered.
So
we
use
the
first
oscar
message
as
an
alternative
success.
Indication
for
the
state
machine
to
release
the
msk
and
then
complete
the
process
and
with
the
recipient
and
sender
id
that
are
now
sent
in
the
previous
message,
we
are
able
to
to
complete
the
whole
process.
The
next
slide,
please.
E
Basically,
we
also
have
a
a
brief
comment
about
the
use
of
proxies,
because
in
the
exchange
there
is
a
role
reversal
in
qua
from
the
first
message
in
which
the
iot
device
acts
as
a
client,
but
on
the
rest
of
the
exchange,
it
is
a
cloud
server
so
this
that
is
something
that
needs
to
be
considered
when
using
proxies
to
send
any
needed
information
to
the
controller,
to
be
able
to
use
the
service
through
a
proxy.
So
this
this
additional
information
could
be
sent
also
in
the
in
the
server
structure
that
it
is
defined.
E
So
we
are
preparing
this
structure.
Maybe
the
next
slide,
I
think,
is:
is
there
yes,
so
we
define
a
silver
structure
that
carries
some
of
the
information
that
we
need
to
exchange
for
cyberspeed
negotiation,
the
sender
id
recipient
id,
also
the
authorization
information
such
as
session
lifestyle.
Maybe
we
can
we
put
it
as
extensible,
so
maybe
we
if
we
need
in
the
future,
to
add
some
additional
information,
and
we
can
do
so
in
this
structure
to
add
maybe
a
further
a
feature
or
another
functionality.
E
E
You
can
see
how
the
context
is
created
when
the
negotiation
is
done
and
basically
when
the
msk
is
derived,
it
is
used,
as
in
the
in
the
seventh
message,
to
complete
the
oscar
context
and
to
send
the
eighth
message
confirming
the
the
key
and
finishing
the
club
exchange.
Lastly,
in
the
in
the
in
the
last
slide,
we
add
in
the
annex
some
considerations
for
using
for
establishing
a
dtls
security
association
that
could
be
used
instead
of
oscar,
and
for
this
we
are
reducing
the
same
fields
as
a
source
core.
E
We
also
do
a
crypto
suite
negotiation
for
for
dtls,
the
key
id
for
the
dtrs
pressure.
Key
is
generated
in
this
case
by
concatenating,
the
center
id
and
recipient
id,
and
in
here,
as
we
do
with
oscor,
we
consider
the
client
hello
message
from
dtls
as
an
urgent
exercise,
indication
to
be
able
to
to
obtain
from
the
state
machine
the
msk
and
be
able
to
run
the
dtis
so
that
that
that's
it.
B
B
H
H
G
G
G
Another
clarification
was
related
to
the
overall
table
of
content
since
texting.
The
draft
was
parsed
here
and
there
with
a
lot
of
repetitions.
So
now
it's
much
more
linear
with
error
handling
mentioned
once
and
for
all
about
its
common
general
part
when
introducing
the
kbc
interface,
and
then
we
go
through
the
resources
at
the
kdc
one
by
one,
followed.
G
By
handler
one
example,
I'm
going
to
example,
and
so
on
in
terms
of
design
changes,
it
was
also
agreed
to
bring
into
this
document
the
definition
already
of
some
parameters
that
were
otherwise
defining
keygroup
common
score
where
they
remain
used,
and
we
define
here
some
new
parameters
for
enabling
control
messages
that
the
kdc
can
send
over
multicast
and,
in
particular,
when
using
advanced
group,
raking
schemes
and
related
to
that
also
a
resource
about
the
public
key
of
the
kdc.
Initially
defining
figure
common
score
was
transferred
here
and
remained
used.
There.
G
G
G
We
introduced
an
optimization
about
possibly
including
public
keys
of
just
joined
new
members
in
the
working
messages,
and
we
give
high-level
guidelines
and
examples
about
different
approaches
that
can
be
used
to
perform
a
group
routine
like
the
very
basic
one-to-one
or
one-to-many,
using
pub
sub
or
multicast,
but
extreme
details
leading
to
actual
content
and
encoding
to
use
on
the
yr
are
up
to
yet
other
documents.
That
should
describe
how
a
particular
raking
scheme
is
used
in
this
context,
possibly
considering
even
the
specific
profile
of
this
document.
G
So
as
a
summary,
this
version
has
addressed
all
the
working
group
last
call
reviews.
As
far
as
I
can
tell
plus
additional
comments
we
got
during
the
july
meeting,
so
we
also
extended
abstract
an
introduction
to
clarify
even
better
the
the
scope
and
the
goals
of
this
document
in
in
this
group
com
landscape,
and
we
also
extended
the
security
consideration
to
highlight
the
the
big
amount
of
trust
that
we
are
putting
on
the
kdc
in
the
first
place
and
what
that
implies.
G
B
G
G
G
Most
of
the
clarifications
that
were
done
in
aceke.com
were
were
also
to
be
done
again
here
for
new
parameters
and
resources
defined
brand
new.
In
this
document
there
was
some
clarification
requested
on
who
can
access
what
resource
to
do,
what
and
on
error
handling
and
on
ayana
considerations,
but
relatively
minor
things.
I
would
say.
G
G
As
a
reminder,
I
have
an
implementation
of
this
draft
for
eclipse
californium,
where
the
group
manager
acting
is
kdc
supports,
but
the
group
mode
and
pairwise
mode
is
used
in
the
score
groups
also
about
this
document.
I'm
not
aware
of
any
further
remaining
issues
or
or
open
points,
so
I
think
it
can
be
considered
now
for
working
group
plus
goal
as
a
heads
up,
the
the
grouposcore
documenting
core
is
also
going
to
approach.
G
Its
second
working
group
last
call,
in
fact,
which
is
good,
but
of
course
we
cannot
exclude
all
together
that
the
group
will
score
documenting
core
with
possible.
Future
updates
is
going
to
to
affect
this
document
in
turn
to
adapt
something
it's
just
the
way
it
works,
as
we
keep
updating
the
documents
in
the
later
stages,
but
right
now
they
are
stable
and
consistent
with
one
another.
B
Yeah,
so
my
my
understanding
for
for
this
document
is
that
we
will
issue
a
walking
deal
classical
very
shortly,
so
you
will
have
a
two
weeks
a
two
week
window.
To
make
any
comment,
I
would
like
people
to
commit
to
review
that.
So
please
I
mean
just.
I
don't
want
to
to
waste
a
lot
of
time
on
that,
but
do
we
have
anyone
in
the
room
that
is
planning
to
review
the
document.
B
B
G
G
G
G
This
document,
in
addition,
so
to
complement,
not
really
replace
an
introspection,
defines
a
new
service,
a
new
interface
at
the
authorization
server
which
basically
preserve,
keeps
one
single
resource.
A
token
revocation
list
intended
to
keep,
let's
say,
short
identifiers
of
tokens
that
are
revoked
at
the
moment,
but
not
yet
expired,
and
then
both
client
and
authorization
and
resource
server.
G
Sorry
register
that
that
authorization
server
can
access
that
resource
through
a
get
operation,
possibly
observe
that
resource
to
be
informed,
possibly
through
automatic
notifications
about
their
pertaining
access,
tokens
that
are
revoked,
but
not
expired
yet,
and
when
doing
so,
they
in
fact
retrieve
information
only
about
the
tokens
pertaining
them,
not
really
all
of
the
access
tokens
issued
by
the
authorization
server,
and
there
is
really
no
need
for
new
ace
endpoints
here,
defined
that
client
or
resource
server.
This
resource
is
at
the
authorization
server
so
for
identifying
these
revoked
tokens
to
inform
about.
G
This
can
work
actually
in
three
different
modes
of
operation
and
the
first
one
is
very
simple
and
mandatory
to
implement
for
the
authorization
server
say.
The
client,
just
like
a
resource
server,
can
send
a
get
or
get
observed,
request
and
retrieve
back
all
the
token
ashes.
For
the
pertaining
token
tokens
that
are
revoked.
G
G
We
defined
bit
more
in
detail
in
the
recent
versions
how
to
format
the
messages
for
the
most
advanced
operation
mode.
Most
recent
review
we
got
or
comments
on
the
list
were
from
michael
richardson
about
a
number
of
very
useful
clarifications
of
different
aspects
of
the
document
that
are
also
integrated
now
in
the
latest
version.
G
The
big
mess
that
we
have
in
mind
is
moving
the
third
most
advanced
mode
of
operation
up
to
the
document
body
and
to
integrate
it
better
with
the
other
two
to
make
everything
look
more
homogeneous.
But
otherwise
we
think
the
document
is
is
stable
in
its
latest
version
and
I'm
aware
of
an
ongoing
implementation
from
a
cnr
research
institute
in
italy.
They
are
building
on
our
implementation
of
va's
framework
on
eclipse,
california,
and
I'm
assisting
with
that.
G
B
B
B
I
Okay,
thank
you,
so
I'm
joran
salander
and
I'm
going
to
talk
about
this
draft.
This
is
just
once
this
presentation
is
just
one
slide
long
and
you
see
the
title
of
the
of
the
sl
draft
here.
The
the
purpose
of
this
draft
is
to
discuss
the
applicability
of
another
draft
with
the
dtls
profile
of
the
ace
framework
to
tls
and
the
content
of
the
draft.
This
was
submitted
late.
I
should
say
so.
I
It
was
in
in
the
two
week
weeks
period
between
the
submission
deadline
and
and
the
meeting,
and
we
just
uploaded
that
on
monday
as
a
compensation,
this
is
a
very
short
draft,
so
the
content
is
essentially
what
stated
in
this
slide.
It's
saying
that
the
dtls
profile
of
ace
applies
to
tls
as
well
as
dtls,
and
we
could
use
the
same
access
token
the
same
profile.
I
A
natural
solution
to
the
authorization
problem,
so
that's
basically
my
presentation
and
and
the
question
is
for
the
working
group
is
first
of
all.
Do
you
think
this
is?
Do
you
like
this?
Do
you
agree
with
this
this
procedure
of
having
a
a
statement
just
about
applicability
of
something?
Do
we
need
a
separate
draft?
Can
we
solve
it
in
some
other
way?
Could
we
could
we,
for
instance,
consider
including
this
sentence,
or
this
paragraph
in
the
ace
details
authorized
draft
which
is
currently
in
auth
48?
D
So
I
mean
yes
you're
right
from
a
technical
sense.
We
could
pull
the
details
profile
back
from
all
48
and
try
to
add
to
it,
but
that's
a
pretty
heavy
hammer
at
this
point
and
I
feel
like
I
would
want
to
redo
like
the
last
call
process
and
get
some
visibility
into
the
iesg
about
it
and
I'm
fairly
reluctant
to
take
that
approach.
F
Yeah,
I
was,
would
it
really
need
the
last
call
isd
added
dtls
1.3
without
having
a
last
call,
I
would
say:
that's
actually
a
bigger
change
than
this
change.
This
would
I
don't
see
any
the
draft
before
mention
some
dtls
one
or
two
details
which
have
now
been
fixed,
but
for
the
tls
I
don't
think
there's
any
changes
needed
at
all
then
you're
saying
what
this
drop
does
that
this
also
works
for
tls.
D
D
D
I
B
My
understanding
is
that
the
request
to
extend
the
dtls
profile
to
tls
I
mean
to
address
the
tls
use
case-
has
been
raised
by
3gpp,
and
so
my
recommendation
is
that
we
had.
We
start
a
working
group
adoption
for
this
document
and
move
that
document.
Pretty
I
mean
pretty
fast,
so
I
would
like
to
have
a
lot
of
people
to
review
this
document
that
is
shorter
than
the
slide.
B
B
Okay,
so
I
I'm
gonna
start
with
a
call
for
adoption,
keep
in
mind
that
we
we
need
to
when
we
adopt
a
document.
We
need
to
make
to
have
a
sufficient
confidence
that
the
document
is
gonna
end
to
to
be
thrown
to
the
isgs.
So,
similarly
to
the
previous
document,
clearly
state
whether
you're,
you're
gonna
review
the
document
or
you
support
it,
and
and
we
will
see
how
it
goes.
G
G
G
And
to
put
all
the
functionalities
in
one
slide
again,
the
root
resource
allows
the
administrator
to
create
a
new
group
or
retrieve
the
list
of
existing
groups,
all
of
them
or
part
of
them,
using
a
fetch
with
a
filtering
criteria
and
then
for
each
child
resource
associated
to
a
particular
oscar
group.
You
can
retrieve
the
current
configuration
so
the
list
of
parameters
describing
how
that
group
works
all
of
them
or
part
of
the
answer
fetch.
G
You
can
entirely
override
the
current
configuration
with
a
new
one
using
put
or,
as
recently
introduced,
you
can
use
a
patch
for
just
selectively
updating
that
configuration
altering
only
some
parameters
or
you
can
delete
all
together.
The
group
configuration
thus
deleting
the
oscar
group
altogether.
G
G
We
started
to
seriously
build
on
on
an
idea
that
christian
triggered
when
this
document
started
about
having
multiple
administrators,
not
only
one
that
can
have
to
do
with
the
same
oscar
group
and
the
direction
we
are
taking
now
is
that
you
have
for
sure
a
primary
administrator
that
creates
a
group
configuration
and
can
do
anything
on
that.
But
at
the
same
time
you
can
also
have
additional
secondary
administrators
that
might
be
allowed
to
do
at
least
something
on
on
the
group
configuration
they
didn't
create
themselves
and
to
practically
enforce
this.
G
Otherwise,
as
I
mentioned,
we
have
recently
introduced
the
possibility
to
perform
a
selective
update
on
the
configuration
on
the
oscar
group
through
patch,
and
while,
if
you
do
a
put,
you
really
override
all
together
a
group
configuration
and
if
you
don't
specify
some
parameter,
you
fall
for
default
values
with
patch.
You
really
act
on
the
only
parameters
you
specify
making
them
take
the
exact
new
value.
You
specify
it's
pretty
straightforward
for
most
of
the
parameters.
G
It's
really
about
specifying
the
pair
parameter,
name,
new
parameter
value,
there's
an
exception
for
a
structured
parameter
up
groups,
which
is
a
list
of
names
or
a
list
of
strings.
If
you
want
to
think
of
that,
so
it's
a
bit
more
tricky
with
with
patch,
but
we
we
have
also
defined
how
that
can
be
handled.
You
basically
have
two
possible
ways:
each
with
pros
and
cons.
You
can't
combine
them
in
the
same
request,
but
you
can
choose
what
better
fits
the
particular
request
ahead.
G
Also,
we
improved
a
bit
how
default
values
are
handled,
speaking
of
which,
as
I
said,
when
creating
a
group
or
overriding
its
configuration
if
a
parameter
is
not
specified,
the
group
manager
is
supposed
to
consider
a
recommended
default
value
in
case
for
some
strong
reason,
the
group
manager
doesn't
do
that
and
goes
for
a
different
value
than
the
recommended
default.
One.
G
G
We
have
also
defined
some
new
configuration
parameters
for
the
oscar
groups
in
case
those
oscar
groups
allow
the
usage
of
cachability
of
responses
protected
with
oscar,
and
that
mechanism
is
defined
in
another
code
draft.
Here
we
just
defined
the
parameters
describing
how
the
group
works
in
that
respect,
so
that
that
information
can
be
consistently
provided
to
to
join
in
nodes
when
they
join
through
the
join
interface
defined
in
the
other
document.
G
This
reference
here
to
korkashabaloskar
is
informative
at
the
moment.
I
think
it
can
remain
for
informative,
because
for
the
sake
of
this
document,
you
don't
really
need
to
understand
how
the
mechanics
of
kashaboloskar
really
work.
You
just
need
to
pick
up
those
two
concepts
here
mapped
into
two
parameters,
so
hopefully
that
can
indeed
remain
an
informative
reference,
but
I'm
happy
to
hear
feedback
in
the
other
direction
in
case
other
than
this.
G
So
that's
just
a
summary
of
what
I've
just
said
for
your
convenience.
Of
course
we
are
not
done
yet.
I
think
the
main
next
step
is
defining
in
detail
the
semantics
we
want
for
for
scope
in
the
tokens
here
so
that
we
can
enable
both
a
primary
administrator,
creating
a
group
and
doing
whatever
it
wants
with
that,
but
also
possibly
additional
secondary
administrator
that
can
do
something
on
groups.
G
They
didn't
create
themselves
and
again
we
have
a
direction
sketched
pretty
well
in
in
the
draft
already,
but
I
was
hoping
that
a
discussion
a
bit
more
in
detail
around
this
to
get
early
feedback
can
happen
at
some
of
the
next
asynchrony
meeting
if
possible
and
just
get
early
feedback,
and
that's
it.
I
think
comments.
Input
are
welcome.
Of
course,.
A
Any
any
comment,
please
christian,
just
briefly
on
the
topic
of
the
informative
reference
to
deterministic
score.
If
that
doesn't
work
out
as
an
informative
reference,
it
should
be
possible
to
just
remove
that
part
and
move
that
part
over
to
deterministic
all
score
where
it
would
then
be
published
later.
So
I
don't
expect
any
showstopper
there.
G
B
I
think
we
we've
had
we've.
We
have
three
minutes
left,
so
I'd
like
to
give
those
three
minutes
to
our
ad
if
he
has
anything
to
say
and
basically
conclude
this
meeting.
So
thank
you
to
all
the
presenters
for
making
that
happen
and
that
we
I
mean
we
were
able
to
to
do
all
the
agenda
items
during
this
meeting
and
I'm
leaving
the
floor
to
ben
and
wishing
you
a
happy
ietf.
D
Yeah
thanks
since
you
passed
it
over
to
me,
I
will
just
say
that
the
main
action
item
on
my
front
relating
to
this
working
group
is
that
the
mqtt
profile
I
know,
has
published
a
revision,
and
I
have
not
yet
had
a
chance
to
look
that
over.
I
expect
that
there
will
be
a
lot
of
good
changes
in
there
and
hopefully
I
can
go
directly
to
a
itf.