►
From YouTube: IETF-ACE-20230605-1300
Description
ACE meeting session at IETF
2023/06/05 1300
https://datatracker.ietf.org/meeting//proceedings/
A
B
C
A
A
C
A
C
A
E
A
E
E
That
yeah,
that's
that's
perfect.
If
everyone
can
see
it,
so
we
had
a
design
meeting
with
Marco
about
outstanding
issues
that
was
presented
in
the
ITF
meeting,
and
what
we
wanted
to
reiterate
is
the
new
message
flow,
which
includes
the
KDC
Discovery
as
well.
So
here
we
assumed
that
the
client
can
do
an
unauthorized
request
to
the
broker.
You
know
they
can
discover
topics
Etc
and
with
the
ace
transport
you
used
would
get.
E
The
AIS
information
then
approach
the
as
to
talk
to
broker
regarding
connecting
to
the
broker
to
figure
out
further
the
KDC
associated
with
the
topics
that
it
wants
to
communicate
to
and
after
that
Discovery
KDC
step.
The
Second
Step
would
be
to
again
approaching
the
as
to
be
able
to
talk
to
the
KDC
and
then
finally,
talking
to
the
KDC
to
join
a
security
group
linked
to
the
the
topics
that
it
wants
to
communicate.
E
This
was
because
I
think
previously
people
thought
when
the
subscribers
joined.
You
know
the
conversation
you
know
by
associating
to
the
broker
they
what
they
would
get
for,
that
topic
would
be
encrypted
Communications
and
since
they
are
not
part
of
a
security
group,
they
would
not
be
able
to
decrypt
that
information.
So
they
don't
need
to
go
additional
steps
of
authorizing
themselves
to
the
broker.
E
We
thought
this
is
not
a
good
idea,
so
we
basically
suggested
that
no
authorized
subscribers
or
no
authorized
Publishers
to
be
able
to
discover
the
KDC
and
an
Associated
Security
Group.
You
need
to
be
authorized
as
well
as
you
need
to
be
authorized
to
be
able
to
join
the
conversation
link
to
that
topic.
So
those
are
the
two
changes
next
slide.
Please.
E
First
of
all,
we
started
the
scope
with
roles
of
Publishers
and
subscribers,
but
then
thinking
actually
what
we
are
adding
to
the
scope
in
terms
of
publishing,
reading
and
deleting
what
we're
adding
is
really
permissions
so
and
there
are
permission
details
that
are
described
in
the
scope,
so
we
we
thought
renaming.
That
would
be
better
in
terms
of
really
describing
what
the
scope
is
about
and
then
previously
in
the
ITF
meeting,
we
suggested
addition
adding
an
admin
permission.
E
E
In
addition
to
that,
we've
talked
about
signaling
what
the
scope
is
about,
whether
it
is
an
application
group
or
a
security
group.
We
thought
this
would
be
especially
important
when
the
same
entity
assumes
multiple
roles
like
KDC
and
the
broker
are
the
same,
and
they
have
to
still
ask
the
as
for
an
so.
The
client
needs
to
still
ask
for
a
token
for
this.
The
same
entity
and
the
audience
would
not
necessarily
differentiate
for
which
role
they
are
talking
to
that
entity.
E
E
E
Described
as
point-to-point
we
we
were
thinking
of
describing
or
thinking
whether
it's
worth
to
add
another
group
re-keying
scheme,
and
then
there
were
additional
operations
supported
at
the
KDC
regarding
policies
and
Etc.
So
these
will
be
done
later
after
the
cutoff
and
that's
my
update
for
the
pub
sub.
B
E
E
We
approach
the
client
approaches
the
authorization
server
twice
once
to
get
a
token
for
the
KDC
he
wants
to
get
to
the
Token
for
the
broker
and
typically,
what
we
describe
in
the
profile
is
that
the
topic
name
was
the
same
with
the
security
group
and
then
the
audience
differentiates.
What
this
token
is
for-
and
who
is
this
token-
is
for
so
Marco
raised
the
issue
of
what
happens
from
the
KDC
and
the
broker
are
the
same
entity.
E
A
F
A
C
Okay,
yeah
hi
everyone.
This
is
an
update
on
the
gym
admin
document
and,
as
agreed
in
the
past
few
meetings
and
entering
meetings,
we
have
now
completed
the
document
split
essentially
taken
out
the
coral
content,
so
the
current
document
say
Doc,
one
is
soon
to
be
just
gmad,
win9
continuing
on
the
same
usual
track.
C
You
can
track
the
changes
on
the
electroscopy
on
the
GitHub
and
again
most
of
the
change
was
extracting
away
the
content
related
to
the
use
of
coral
while
keeping
the
the
main
interface
protocol
and
its
use
with
seabor
and
Link
format
yeah.
We
also
noted
some
remnant
from
from
last
year,
if
not
older,
about
how
the
group
managers
should
consider
the
pairwise
mode
to
be
by
default.
C
So
we
think
it's
just
more
appropriate
to
have
it
through,
but
it's
a
simple
change
and
then
we
took
the
opportunity
Also
to
clarify
better
what
happens
when
group
members
learn
of
group
configuration
change
just
in
spanning
on
the
content
we
had
already
and,
of
course,
a
number
of
editorial
improvements,
but
then,
in
parallel
side
by
side
with
the
extraction
we
also
set
up
the
soon
to
be
a
GM
admin,
Coral
zero,
zero.
It's
now
completed
a
stable.
A
C
Okay,
sorry
yeah.
In
the
co-working
group,
we
are
processing
the
chapter
review
of
the
group
of
score
document
and
when
working
on
that,
we
noted
two
open
points
for
this
GM
admin
document
here
to
be
addressed
accordingly,
more
details
in
the
next
slide,
but
one
is
an
actual
clarification
in
the
protocol
and
one
is
more
a
matter
of
consistency
fix
in
terms
of
technology
to
remain
consistent
with
with
Grupo
score.
C
So
on
the
first
open
Point.
This
was
around
all
along
actually,
but
again,
we've
just
noticed
considering
work
happening
in
the
co-working
group.
The
administrator
is
in
general,
able
to
change
the
current
configuration
of
the
group
at
runtime
and
it
may
sound
a
bit
Reckless,
but
the
administrator
May
in
principle
change
the
encryption
algorithms
used
in
the
group.
C
So
those
group
members
would
practically
have
an
identifier
that
is
not
consistent
and
usable
in
the
group
anymore
at
that
point,
so
just
in
the
interest
of
avoid
something
very
complicated
or
to
shut
down
the
group
altogether,
which
would
be
also
an
overreaction.
If
there's
no
objection,
our
proposal
would
be
in
this
particular
Corner
case
for
the
group
manager
to
evict
from
the
group
specifically
those
group
members
that
now
have
basically
an
inconsistent
two
large
sender,
ID.
We
don't
need
to
explain
how
that
particular
step
happens.
C
Sorry,
my
connection
is
bad.
Today
I
was
saying
the
king
process
itself
is
already
taken
care
of
in
another
document,
but
I
think
in
this
document
we
should
at
least
say
that
this
direction
is
taken
in
this
corner
phase,
and
it's
neither
it's
nice
that
we
can
say
that
once
and
for
all.
In
one
particular
section
discussing
this
configuration
overwriting
with
a
put
Handler,
we
don't
need
to
re-explain
in
another
section.
C
That's
just
inherits
this
side
effects
silently
we
don't
need
to
re-explain
it
again
in
the
admin
Coral
document
I
mentioned
above
that
inherits
this
silently
as
well.
So
if
there's
no
yeah
a
smart
alternative
or
objection
against
this
I
proposal
would
be
to
to
explain
this
Way
Forward
in
section
662.
C
C
Okay,
thanks
yeah,
the
second
one
is
easier:
it's
really
about
terminology
and
naming
for
the
sake
of
consistency
with
group
of
score.
It's
about
changing
the
name
of
an
algorithm
and
the
name
of
a
parameter
reflecting
another
another
algorithm
that
has
to
be
fixed
accordingly,
also
in
the
in
the
coral
document,
especially
in
the
examples.
C
C
Something
more
will
be
left
there,
but
it
shouldn't
really
affect
what
happens
in
this
document
instead
and
then
we
finalize
GM
admin
to
be
Version
9,
according
to
the
previous
slides,
we'll
submit
it
as
version
nine,
and
we
follow
up
right
away
with
version
zero
of
the
coral
document
and
when
we
get
there,
we
should
definitely
have
the
GM
admin.
Version
9,
ready
to
consider
for
a
working
group
plus
call.
A
C
Okay,
thanks
by
the
way
I
proposed
an
additional
legal
set
of
slides
on
key
group,
home
and
kiguru.com
Oscar
no
need
to
go
through
them.
I
I
just
cared
about
having
them
archived
for
the
meeting
material,
but
long
story
short,
also
also
related
to
the
terminology
issues
I
mentioned
above
I'm
just
going
to
open
some
issues
on
the
GitHub
for
both
kigu
com
and
kirukon
Oscar,
especially
on
the
terminology
alignment
again
to
not
revise
the
drafts
right
now
and
to
wait
for
doing
that
after
the
the
ad
review.
C
G
We
published
revision01
during
the
the
past
weekend
this
this
revision
resolves
all
the
comments
and
issues
that
Marco
raised
in
his
review.
Once
again,
I
would
like
to
thank
Marco
for
his
review,
and
the
goal
of
today's
presentation
is
to
to
discuss
one
of
the
open
points
that
was
raised
by
Michael.
G
What,
during
the
discussion
on
the
pull
requests
in
the
repository
and
also
to
present
the
resolutions
to
the
issues
from
the
last
interim,
so
I
will
for
in
the
interest
of
time
and
I
will
first
go
with
the
open
issue
and
then,
after
at
the
end,
present
the
resolutions
to
the
issues
from
the
last
meeting.
So
the
open
issue
that
was
raised
by
Michael
is
on
server
generated.
G
G
A
Michael
says
he's
an
Aussie
place,
so
he's
not
getting
everything,
but
he
says
he
doesn't
buy
the
without
an
OS
point.
He
says
if
there
could
be
a
matter
when
we
need
to
code
beam
it
or
secure
RNG,
or
we
will
have
lots
of
problem.
He
says
that
he
hasn't
watched
this
YouTube
video
and
when
he
says
other
people
are
working
group
who
want
server
generated
keys
that
rhymes
video,
he
says
I
don't
object,
but
he
questions
the
need.
G
Okay,
so
I'm
not
arguing
that
it's
good
to
have
server
generated
keys
with
so
oh
okay,
so
Paul
is
saying.
I
would
be
okay
with
the
big
fat
warning
that
it
should
not
be
done
unless
absolutely
no
other
way
possible.
So
yeah
I
think
this
was
my
proposed
Way
Forward
instance
and
I
think
it's
seconds
what
joran
said
about
having
a
big
security
consideration
section
on
secure,
render
on
server
generated
private
keys,
so
so
I
think
also,
if
we
we
will
be
compatible
with
RFC
9148.
G
A
A
E
G
Okay,
so
maybe
to
respond
to
Michael's
comment
about
bare
metal,
then
they
need
to
code
bare
metal,
secure,
RNG
or
they
will
have
lots
of
problems.
So
this
is
true.
This
is
true.
I
do
not
support
or
I
mean
it's
I'm,
just
stating
the
fact
that
some
vendors
are
using
bare
metal,
bare
metal,
programming
approaches
but
yeah.
G
If
we
want
to
secure
RNG,
then
the
best
way
forward
as
it
is
outlining
this
stock
is
to
have
multiple
sources
of
entropy
and
not
a
single
source
of
entropy,
and
that
this
needs
to
be
implemented
properly.
So
it's
more
the
matter
of
what
is
the
state
of
practice
today
and
whether
we
should
still
allow
to
be
on
the
safe
side,
allow
an
option
so
I
think
allowing
an
option
with
the
warning
is
fine,
with
the
good
consideration
explained
in
the
draft,
so
I
would
propose
that
way
forward.
Then.
A
D
B
D
G
So
maybe
I'm
making
a
little
digression
for
yes,
so
if
you're
only
stating
something
for
the
things
to
things,
research
group,
perhaps
but
I
would
just
maybe
to
make
little
regression
Cards
into
what
you
said
that
even
the
new
new
processors
have
good
support.
I
was
surprised
when
I
actually
followed.
This
talk
that
some
very
prominent
examples-
I
won't
name
the
vendors
now,
but
some
very
prominent
or
new
processors
that
have
Hardware
support
for
rngs
have
been
shown
to
have
very
vulnerable
implementations
of
them.
G
F
G
G
G
Okay,
thanks,
so
I
will
now
go
through
the
result,
issues
from
the
last
meeting.
They
kept
the
same
ordering
from
the
last
interim
when
we
discussed
them
and
I'm,
including
just
a
snapshot
of
the
pull
request
that
was
introduced
in
the
repository
on
on
each
specific
issue.
So
this
is,
this
should
be
non-controversial
it
it's
just
the
implementation
of
what
we
discussed
in
the
previous
meeting.
G
So
this
issue
is
to
explicit
the
message
flow
so
where
we
are,
we
are
forcing
the
ad
hoc
client
to
play
the
role
of
the
the
ESD
client
and
ad
hoc
respond
ad
hoc
initiator
to
play
the
role
of
the
ESD
client
and
the
ad
hoc
responder
to
play
the
role
of
the
EST
server.
So
this
pull
request
did
that,
if
are
there
any
comments
on
this.
G
And
yes,
in
the
process
of
doing
this,
I
I
found
out
some
normative
keywords
that
were
used
unnecessarily.
Essentially,
what
custom
called
restatement
anti-pattern
if
I
recall
correctly
so
I
this?
This
is
lowercasing.
These
keywords
the
CL
on
essentially
that
are
coming
from
the
requirements
of
ad
hoc,
so
logical
consequences
of
implementing
ad
hoc.
G
G
G
So
this
is
non-controversial.
This
was
a
comment
by
Marco,
where
he
was
essentially
questioning
why
we
were
not
transporting
pkc
as
objects
in
EAD
ad
hoc
items,
and
the
reason
for
this
was
because
was
because
we
are
considering
re-enrollment,
where
use
of
ad
hoc
is
not
necessarily
where
ad
hoc
is
not
necessarily
used.
So
we
added
an
informative
statement
that
EAD
items
are
not
used
because
of
ad
hoc
is
not
necessarily
used
in
the
case
of
re-enrollment.
G
The
comment
was
that
in
Oscar,
RFC
8613,
the
osc
attribute
is
optionally
included,
but
here
in
our
configuration
where
we
can,
where
we
can
also
use
where
we
can
use
dtls
where
we
can
combine
the
use
of
oscore
ndtls.
The
this
attribute
is
indeed
required
in
order
to
signal
to
the
clients
that
the
resources
that
this
is
an
EST
server
using
EST
Coopers,
that
is
using
ESD
oscore
and
not
EST
Coopers.
G
G
G
What
we
did
here-
and
this
essentially
depends
on
whether
the
client
included
in
the
certificate
signing
in
the
CSR
included
the
S
mime
capabilities,
which
signals
whether
it
the
response
should
be
encrypted
or
not.
So
when
making
the
the
CSR
to
SKC
and
skg
the
we
mandated
that
the
ESD
client
must
not
include
sman
capabilities
and
there's
a
consequence
of
that,
the
private
key
part
of
the
response
to
SKC
or
skg
is
an
is
an
unencrypted
pkcs
8
object.
So
this
is
essentially
implementing
what
we
discussed
during
the
last
meeting.
G
Then
we
worked
on
the
content
format,
identifiers,
where
Marco
brought
up
that
it
would
be
good
to
just
like
in
RFC.
9148
include
the
summary
of
what
is
supported
and
we
added
an
explicit
statement
on
the
content
format
support
this
is
the
the
green
stuff
here
in
the
middle,
and
we
also
added
a
table
on
on
the
summary
of
the
response:
content
format,
identifiers
for
SKC
and
skg
server
generated
Keys,
which
are
now
unencrypted
PK
cs8
objects.
G
Then,
during
the
last
meeting,
we
discussed
restatement
at
the
anti-pattern
in
message
binding
section.
This
was
brought
up
by
Karsten
and
the
action
was
to
avoid
this.
This
pattern
by
informative
text.
So
essentially,
what
we
did
is
we
made
the
text
informative
by
preceding
it
with
note
that,
and
it
is
therefore
required
that
the
implementation
supports
implements
given
options
from
the
from
the
references
and
later
we
specify
exactly
in
slide
16.
G
So
this
is
on
block
one
and
block
two
where
we
follow
where
we
somewhat
follow:
RFC
9148,
essentially
right
now.
What
we
specify
is
that
the
servers
must
Implement
both
block,
1
and
block
two,
and
that
Oscar
clients
must
Implement
block
2
and
may
Implement
block
one
which
is
used
in
the
request.
So
essentially
it's
up
to
them
whether
they
want
to
fragment
using
block
one
in
the
in
the
requests.
D
G
D
G
G
So
we
agreed
in
the
previous
meeting
to
informatively
reference
this
draft
as
a
way
to
establish
a
secure
association
between
DST,
client
and
Co-op
to
HTTP
proxy.
So
yes,
in
the
first
two
changes,
it's
just
the
sentence
being
brought
to
a
new
line
and
then
the
new
sentences
reads:
if
a
secure
Association
is
needed
between
the
SD
client
and
the
comp
to
http
HTTP
proxy.
This
may
also
rely
on
a
score
referencing
Marcus
draft.
G
Specified
translation
number
15
specified
translation
scheme.
If
dtls
is
additionally
used.
Essentially
we
were
missing.
We
were
being
specific
that
EST
URLs
based
on
https,
are
translated
to
co-op
when
Oscar
is
used,
but
in
case
dtls
is
additionally
used.
The
translation
Target
is
this:
is
the
scheme
quad
s,
so
this
was
just
the
clarification
in
in
the
draft,
so
that
would
be
the
last
resolution
of
the
items
from
the
previous
meeting.
G
With
that
we
are,
we
are
we
have
action
items
to
essentially
expand
on
the
security
consideration
section,
especially
now,
with
regards
to
server
generated
keys
and
also
some
other
aspects
in
the
draft
triple
related
to
channel
binding
using
ad
hoc
and
the
triple
Shake
attack
that
RFC
9148
counters.
So
we
will
be
expanding
on
that
before
and
Publishing
a
new
version
before
the
cutoff
for
for
the
next
ITF
and
we
hope
to
receive
new
reviews
that
would
help
us
progress.
This
specification
further.
B
You
can't
hear
me
you
can't
hear
me:
yes,
I
can
hear
you
now.
Okay,
great,
there
is
no.
We
are
working
on
it.
There
is
no
update
for
this
meeting
on
the
on
the
adult
profile,
so
we'll
get
back
on
that,
probably
at
the
ITF
meeting
in
San
Francisco,
because
there
is
some
some
vacation
time
now
between
now
and
the
cutoff
sorry
between
now
and
the
next
in
three
meeting,
so
so
that
would
probably
not
be
any
not
much
progress.
So
we
can
that
we
can
present.