►
From YouTube: ACE WG Interim Meeting, 2021-10-12
Description
ACE WG Interim Meeting, 2021-10-12
A
A
B
A
A
B
B
B
A
B
So
we
just
tried
to
consider
the
use
of
non-conformal
messages
because
of
the
one
of
one
phrasing
in
a
review
that
actually
added
more
complexity
to
the
to
the
solution.
So
at
this
point
actually
we
are
basically,
as
we
were
at
the
beginning,
so
everything
is
as
it
should
be.
There
is
no
problem
with
the
ip
state
machine,
because
actually
we
are
assuring
that
the
message
is
going
to
arrive
as
as
expected
and
and
we
are
keeping
actually
the
ordering
warranty,
etc.
B
B
So,
basically,
just
regarding
the
discovery
of
the
ipod
indicator
at
first
we
say
that
this-
this
is
actually
something
that
is
out
of
the
scope
of
the
document,
but
we
may
add
some
discussion
about
how
this
could
be
done,
but
this
is,
this
would
be
not
would
not
be
the
focus
of
the
document.
So
there
are
some
ideas:
how
to
get
the
ip
of
the
of
the
authenticator
under
the
assumption
that
it's
in
the
border,
router
and
other
mechanisms,
but
the
idea
is
to
leave
the
discovery
out
of
the
scope.
E
B
Not
to
be
processed
so
because
the
iot
device
is
always
creating
a
specific
resource
to
process
the
authentication.
We
are
reducing
the
cases
where,
where
some
entities
sending
a
message
that
that
does
not
belong
or
does
not
have
to
be
processed
so
that
that
basically,
is
the
other
change
that
we
are.
We
are
integrating
and
the
next
slide
please
so,
basically
after
another
meeting
with
with
christian,
actually,
we
we
decided
also
to
keep
the
original
design
of
using
oscor
for
doing
the
key
confirmation.
B
B
B
B
So
in
this
case
you
can
see
how,
in
the
first
message
number
one,
we
are
not
only
sending
the
the
request,
identity
message,
but
we
are
also
sending
the
cryptoshoot
negotiation
for
oscor
and
the
sender
id
and
the
same
happens
in
the
message
number
two,
where
the.
If
response
identity
is
sent
along
with
the
cipher
suite
chosen
for
oscar
and
the
recipient
id
after
all,
this
has
finished
in
the
ipsuccess.
B
A
B
The
negotiation
is
done,
but
without
the
key
that
is
obtained
on
the
message
message:
7
that
is
treated
as
an
alternative
test
indication.
The
oscar
context
is
then
completed
and
we
can
send
the
message
8
performing
the
key
confirmation
with
the
controller.
This
way
we
will
be
finishing
the
the
the
complete
flow,
maintaining
the
oscore
exchange,
as
we
initially
intended
just
a
minor
detail.
B
A
B
It
was
a
mixed
spell:
it
was
a
silver
containing
additional
information
or
timeout,
etc.
So
the
idea
is
to
place
the
information
in
such
a
way
in
the
club
payload
to
carry
the
the
additional
information
that
we
need,
and
the
idea
is
for
this
structure
following
actually
suggestion
to
make
this
structure
extensible.
E
B
B
Sure
the
the
idea
basically
is,
we
are
using
a
from
the
os
core,
the
the
the
the
three
para
parameters
that
are
needed,
therefore,
for
the
the
establishing
the
the
oscar
security
context,
this
would
be
chosen
think
actually
pretty
similarly
to
what
what
you
are
doing
in
escrow,
but
with
less
information,
because
in
this
case
we
we
are
only
using
or
transmitting
information
about
what
concerns
to
oscore
and
the
idea
to
to
somehow
protect
it.
This
protection
would
be
done
later
by
binding
this
information
into
the
key
derivation
process.
B
So
we
take
the
negotiate,
the
information
that
is
exchanged
in
the
negotiation.
If
this
information
is
bound,
it's
ba
bounded
to
the
key
derivation
process.
So
if
there
is
any
alteration
or
attack
or
mathematic
media
attack
or
something
with
that
tries
to
perform
a
downgrading
attack
or
or
some
other
alteration
of
the
content,
the
confirmation
would
fail.
E
E
E
A
E
B
B
A
A
A
A
A
A
D
A
A
A
A
A
Since
it's
already
pre
pre-registered,
but
if
we're
using
it,
we
should
make
sure
that
I
mean
there
is
a
temporary
registration
as
far
as
understood,
and
we
just
make
sure
we
need
to
make
sure
that
the
I
and
I
understand
that
this
registration
concerns
now
two
drafts
and
should
not
remove
it.
If
the
other
draft
is
not
moving
ahead.
For
example,
it.
D
A
A
A
G
G
Yeah,
there
were
two
reviews
in
fact
that
were
mentioned
already,
and
we
went
through
them
at
the
past
interim
from
iran
and
and
seek
them.
There
were
early
exchanges
with
jordan
already
and
we
had
more
exchanges
with
sick
them
this
morning.
Actually,
although
it's
not
captured
in
this
slide,
but
you
see
that
already
on
the
list-
and
if
you
remember
from
the
previous
meeting,
the
many
comments
were
split
into
editorial
clarification
and
design
changes.
G
Let's
say
I'm
done
with
the
editorial
things,
though,
that
they
keep
coming
up
here
and
then
but
they're
easy
to
fix.
I
think
I'm
almost
done
with
qualifications
and
I
believe
I'm
done
with
design
changes,
but
I'll
really
need
to
go
through
them
and
double
check
and
you'll
be
good
to
have
also
feedback
from
the
reviewers.
I
really
addressed
everything.
G
G
G
Okay
next
slide,
please
yeah
just
trying
to
give
a
server
what
I've
done
and
skipping
the
editorial
things.
Of
course,
selective
qualifications
were
where
many
already
seeked
and
wanted
to
have
already
an
early
definition
of
group
from
what
we
really
mean
with
that,
which
is
a
security
group
and
the
encoding
of
some
messages
that
doesn't
really
deviate
from
ace
anyway.
Joran
had
several
comments
on
on
the
parts
about
posting
or
less
ambiguously,
transferring
the
token
to
the
kdc
and
the
parameters
involved,
and
that
should
be
also
clearer.
G
Now
and
sigdom
had
many
comments
on
the
joining
process
as
such
and
details
of
its
messages.
I
think,
especially
on
the
first
and
last
sub-bullet
point
here
so
approaches
for
early
discovery
of
the
group
for
adjoining
client
and
concrete
examples
of
what
we
can
transport
into
this
management,
key
material
that
that
starts
making
sense
only
if
you
consider
more
advanced
group
ranking
schemes,
so
this
should
also
be
addressed
now,
but
again,
these
are
just
the
clarifications
next
slide.
Please
right!
G
These
kind
of
things,
I
think
both
sig
dem
and
joram,
wanted
and
the
first
one
essentially
resulted
in
in
a
new
table
of
content,
which
I
believe
is
much
better
and
linear
to
follow
now.
So
it
overviews
the
interface
and
the
operations
that
the
kdc
provides,
and
then
it
goes
one
by
one
through
each
resource
at
the
kdc
providing
a
certain
functionality.
G
It
describes
the
handlers
for
those
resources
and
then
an
example
for
each
of
those
in
a
very
linear
and
predictable
way,
and
also
seek
them
notice
that
there
was
a
lot
of
redundant
text
about
error,
randling
that
was
common
to
all
or
most
the
handlers
that
was
repeated
over
and
over.
So
I
actually
managed
to
find
what
was
really
common
and
put
that,
on
top
on
a
dedicated
section
about
error
handling
and
a
few
things
specialized
on.
G
So
those
were
those
were
the
clarifications.
There
were
a
bit
bigger
design
changes
here,
also
discussed
in
the
reviews,
and
these
ones
are
basically
related
to
enabling
a
more
efficient
group
wrecking
schemes
rather
than
basic
point-to-point
approaches,
but
rather
relying
relying
on
one-to-many
delivery
working
messages,
for
example
over
multicast,
and
we
realized
this
required
to
introduce
to
start
a
number
of
parameters.
G
Those
working
messages
are
supposed
to
be
signed
by
the
kdc
to
ensure
source
authentication
which
brings
in
the
the
public
key
of
the
kdc
as
well
to
be
provided
to
the
johnny
nodes.
This
is
something
that,
for
different
reasons,
we
were
doing
in
the
keygram
score
document,
so
something
could
be
imported
from
there
and-
and
I
imported
here,
meaning
the
first
set
of
parameters
you
see
on
top.
G
G
G
So
profiles
can
can
make
these
things
stricter
than
they
are
here.
Some
parameters
defined
here
instead
are
just
conditional
to
particular
situations
to
happen
or
conditions
to
be
verified,
and
then
it's
a
separate
requirement
for
profiles
to
to
say
the
last
word
and
based
on
those
conditions
that
can
be
profit
specific,
take
a
final
decision
and
say:
okay
in
this
profile.
That
parameter,
then,
is
a
must
parameter
and,
of
course,
the
profiler
defines
a
brand
new
parameter
of
its
own.
That
parameter
has
to
be
categorized
according
to
the
same
taxonomy.
G
So
since
this
is
using
a
content
format
that
we
have
for
all
messages
anyway
and
it's
aligned
with
other
enhanced
error
messages
in
ace,
it's
a
cheap
way
to
give
a
better
hint
to
devices,
especially
the
the
error
integer.
But
we
have
also
clarified
that
there's
really
no
use
for
the
textual
level
description
if
no
human
intervention
is
expected
and
the
kdc
is
supposed
to
log
any
error
event
anyway,
and
then
there's
also
separate
categorization
of
what
operations
the
kdc
provides.
G
So
the
kdc
itself
is
supposed
to
really
support
everything
unless
a
profile
says
otherwise,
because
something
is
really
not
needed
at
all.
But
for
for
the
device
for
the
group
members,
I
split
these
operations
into
a
primary.
I
call
them
so
really
to
be
minimally
supported
and
and
secondary
to
be
additionally
supported
when
when
it
is
not
strictly
needed,
maybe
because
of
the
roles
that
the
device
wants
to
have
in
the
group
and
new
functionalities
introduced
by
profile
have
to
be
categorized
according
to
the
same
way
of
thinking
next
slide.
G
Please-
and
this
would
be
the
last
point
of
the
design
changes
and
it's
probably
the
biggest
one,
and
we
really
really
need
a
good
re-review
of
this
content,
which
is
now
a
new
section.
Six
of
about
seven
pages,
it
was
noted
that
all
the
content
about
the
group
ranking
was
scattered
here
and
there
in
the
draft.
So
the
first
thing
was
collecting
it
in
a
single
draft,
and
then
it
had
to
take
into
account
related
comments,
some
of
which
I
mentioned
in
the
previous
slides.
G
Members
can
also
take
the
opportunity
to
provide
the
public
keys
of
those
new
group
members
so
sparing
separate
traffic
later
on
as
an
optimization,
it's
of
course
optional
to
do,
and
then
the
section
continues
giving
more
detail
on
what
is
the
basic
point-to-point
wrecking
approach,
which
is
supposed
to
be
really
supported
minimally
by
the
kdc
to
use
and
some
practical
recommendations
and
guidelines
on
on
variations
of
it,
for
instance
based
on
co-op,
observe.
But
then
it
continues
opening
for
more
efficient
approaches
and
that
can
be
defined
somewhere
else,
but
still
gives
guidelines
here.
G
So
you
can
rely
on
efficient
delivery
of
wrecking
messages,
for
instance
over
multicast
or
through
a
pub
sub
architecture,
and
regardless
the
exact
way
you
used
to
deliver
these
messages.
It
also
give
hints
and
very
high
level
examples
on
how
that
can
work
and
how
you
may
use
cosi
to
protect
those
working
messages
at
the
application
level
with
the
dedicated
administrative
key
material.
G
But
the
details
are
very
specific
to
the
exact
raking
scheme
you
use
like
the
the
real
algorithm
used
and
the
message,
format
and
content.
So
I
would
expect
totally
different
documents
to
take
this.
As
a
starting
point
and
to
make
a
profiling
of
a
group
raking
scheme
in
this
context,
and
possibly
even
taking
into
account
application
profiles
of
this
document-
and
this
is
also
all
explained
in
that
section-
I
I
think
again
it's
really
really
important
to
do
a
re-review
of
this
content.
Now,
because
it's
a
lot
and
it's
mostly
new.
G
A
Okay,
so
well,
I
I
I
think,
given
the
I
mean,
the
the
people
that
reviewed
it
are
basically
sig
dem
and
current,
so
I'm
wondering
if,
if
it's
feasible
for
that
you,
you
see
you
see
with
them.
If
they
can
have
a
look
at
it
before
you
publish
so
that
we
we
can
speed
up
a
little
bit
the
and
and
when
it's
published
we
at
least
have
I
mean
we
already
had
reviews
from
the
the
two
reviewers.
E
G
A
G
G
G
Yeah
this
this
is
just
this
is
just
the
list.
Basically
all
the
changes
I
mentioned
before
resulted
in
a
lot
of
new
requirements.
I
think
rec
2
is
unrelated
to
what
I
showed.
It
was
just
missing
all
time,
but
all
the
other
ones
were
related
to
these
changes
and
yeah.
I
had
to
define
them
and
I
have
to
remember
everything-
and
this
is
the
number
the
numbering
today.
Of
course
it
can
change
again,
but
at
least
it's
consistent.
G
Yeah,
it's
caring
and
by
the
way
I
split
the
appendix
to
the
requirement
now
into
two
clear
subsections
to
have
first
the
mandatory
to
address
requirements
and
then,
as
a
separate
subsection,
the
optional
ones
just
for
for
the
sake
of
reading
yeah.
I
think
I've
covered
all
points
from
the
reviews.
As
far
as
I
can
tell,
but
I
I
really
have
to
double
check
and
I'm
still
hoping
I
can
read
from
top
to
bottom.
I
I'll
probably
have
to
harmonize
a
lot
of
terminology
here
and
there
in
polish.
G
There
are
still
a
few
clarifications
to
give
for
points
that
were
raised
in
the
july
meeting
about
clarifying
even
better.
The
overall
goal
of
this
document
is
scope
and
what
covers
basically
in
the
abstract
and
the
introduction,
and
be
very
explicit
about
what
we
assume
about
the
kdc
to
be
a
very
trusted
node
and
and
about
the
secure
interactions
with
it.
G
But
all
I've
presented
so
far
is
already
in
the
elector's
copy
and
yeah
I'll
keep
working
to
deliver
the
best
I
can
for
the
cut
off
in
parallel.
Of
course,
I'm
working
on
ki
grukomoscore
by
the
way.
Since
it's
next
item
in
the
agenda,
but
this
line
is
the
only
thing
I
have
to
say
it
was
mostly
about,
as
I
said
before,
moving
content
out
of
it
to
bring
it
into
this
document
and
to
reflecting
key
group
common
score
things
as
they
changed
here.
Instead,.
A
G
As
to
the
relation
it
has
with
the
documenting
core,
keygroup
score
was
stable
already
in
july
yeah.
Actually,
so
I
I
it
is
still
stable
in
that
respect.
It
is
still
being
updated,
mostly
because
of
what
is
happening
in
this
document
now.
Okay,
so
still
still
bearing
a
careful
proof,
reading
and
so
on
and
so
forth.
That
document
is
pretty
stable
too.
G
G
A
A
E
Yeah
for
marco,
so
thank
you
very
much,
marco
for
doing
all
this
work
very
painful,
like
einstein,
so
the
purpose
of
all
these
comments
was
to
to
clarify
some
of
the
mandatory
parts
of
the
specification
and
also,
at
least
for
for
me,
make
it
easier
to
to
read
and
and
well
in
terms
of
how
things
are
introduced.
But
what
is
your
feeling
now
after
having
done
this
is?
Was
it
worth
the
exercise
or
did
we
get
a
better
document
out
of
it
or
I.
G
G
A
A
A
B
A
So
I've
received
an
email
from
sig
dem
this
morning.
It's
about
the
pub
sub,
so
she
is
updating
it.
So
sigdam
can't
attend
this
meeting
because
she's
giving
some
lectures
and
so
she's
reviewing.
So
she
received
some
comments
from
marco
she's
updating
the
document.
She
needs
to
clarify
some
of
the
things
with
francesca
and
but
that's
hopefully,
by
the
end
of
the
month,
we
should
have
something,
so
I
suspect
that
we
will
reach
also,
I
mean
the
document.
A
A
Yeah.
I
think
we
we're
progressing
well.
As
far
as
I
see
is
that
the
the
time
frame
before
I
receive
some
updates
for
the
meeting
and
the
meeting
is
now,
it's
now
almost
live,
but
that's
so
I
I
think
it's
important
that
we
keep
those
interior
meetings
to
to
make
some
progress
and
and
yeah.
So
basically,
I'd
like
to
thank
you
all
for
the
effort.
You're
doing
I'm
wondering
logan.
Do
you
have
anything
to
add
or.
G
Marco
here
I
have
an
administrative
comment
on
the
gm
admin
document
actually
on
which
I
plan
to
have
very
small
updates
by
the
way,
because
I
have
to
prioritize
giggle
com.
The
comment
is
about
the
github
repo
for
the
document.
There
must
be
some
misconfiguration,
because
the
editor's
copy
is
not
really
built.
G
I'm
posting
the
link
to
the
main
ripple
here.
So
anything
else
work
in
the
rape
of
the
the
branches,
the
the
building
and
everything,
but
the
core
building
of
the
electroscopy
doesn't
work,
and
I
don't
think
I
have
the
privileges
to
to
change
any
of
this.
So
just
in
case
the
chairs
can
can
possibly
fix
that.
It's
not
urgent,
but.