►
From YouTube: IETF101-ACE-20180319-0930
Description
ACE meeting session at IETF101
2018/03/19 0930
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
A
A
B
On
this,
as
soon
as
I
just
wanted
to
note
that
there's
a
site
meeting
during
lunch
about
the
topic
that
is
related
to
the
work
here
on
sort
of
application
layer
TLS
on
ascend
to
this
Atlas
mailing
list
I
can
forward
the
logistic
information
to
there
for
the
ACE
mailing
list.
If
someone
is
interested,
yeah.
A
So
this
first
bullet
point
might
look
a
little
bit
familiar
to
those
of
you
who
were
in
Singapore,
but
it
turns
out
that
I'm
going
to
be
starting
as
security
ad
in
a
few
days,
so
I
will
not
be
able
to
beach
here
anymore.
But
thank
you
to
Roman,
who
is
offered
to
step
in
and
take
over.
For
me,
I'm
sure
he'll
do
a
great
job,
and
the
next
item
is
also
pretty
exciting.
C
C
C
Jim
looking
at
the
email
I
think
you
still
owe
suggested
text
on
a
couple
of
them.
If
you
want
to
pursue
those-
and
there
was
one
way
you
asked
to
like
restructure
the
text
in
a
major
way-
and
maybe
we
can
talk
about
that,
but
what
we
had
done
intentionally
was
have
the
sections
and
the
definitions
follow
the
proof
of
possession
draft
which
is
RFC
7800
and.
C
We
believe
that
this
is
essentially
done.
Itf
99
we'd
agreed
to
try
to
do
this
fast
because
it's
a
simple
draft
that
just
is
effectively
a
syntax
transformation
from
an
RFC
that
already
exists
from
Jason
to
see
more.
As
the
chairs
just
noted,
the
Seaboard
web
token
is
now
in
the
RFC.
Editor
queue
they're
right
that
I
will
publish
one
draft,
which
just
adds
the
same
phrase
in
a
few
places
saying,
as
defined
in
section
such-and-such,
so
no
actual
changes.
C
At
least
that
editor
is
believed
that
this
is
ready
for
working
group.
Last
call
there's
been
no
semantic
changes
to
it
during
the
lifetime
of
the
draft.
There
have
been
improvements
in
exposition
and
I
expect
that
in
working
group
last
call
we
will
continue
to
get
suggestions
for
improvements
in
the
exposition.
C
D
This
is
the
eesti
of
a
coal
best
draft,
which
has
recently
been
adopted
as
a
broken
cooktops.
Thank
you
very
much
appreciate
that
what
it
does
it's
tells
about
enrollment
of
over
secure
transport,
but
instead
of
using
the
standard
TLS,
it
uses
the
Detailers,
and
that
is
dumb
for
constrained
devices.
D
There
has
been
a
major
progress,
yeah
the
man.
The
most
major
progress
is
that
the
draft
has
been
separated
in
parts
where,
before
it
was
very
much
focused
on
the
Brisky
extensions,
they
have
all
been
removed,
and
it
is
now
purely
est
of
corpus,
Thank,
You
Hamish,
for
making
this
possible
as
well,
and
so
what
this
graph
does
is
just
eesti
of
copass
and
all
the
other
extensions
like
motifs,
the
voucher
stated
etc
are
used
for
Brisky
is
done
to
another
graph
which
is
currently
being
presented
to
anima
further
reduce.
D
D
D
Then
there
was
the
suggestion
that
the
circuit
generation
may
only
use
cozen
and
we
are
not
determined
about
how
to
do
that.
Yet
then
there
was
the
suggestion
that
we
have
these
long
names
and
the
short
names
for
the
functions
and
the
operations
and
that
we
will
use
in
May
and
a
must,
as
is
suggested,
Peter.
B
D
As
far
as
I
know
for
mum
of
my
co-authors,
that
they
wanted
to
use
the
surfer
key
generation
for
one
of
the
applications
and
so
for
that
cave.
For
that
reason
they
thought
it
was
important
and
but
they
were
concerned
actually
about
how
to
actually
protect.
Then
the
transport
of
this
new
generated
key
and
they
saw
that
it
could
be
handled
by
having
the
the
keys
already
pre
distributed
them.
Well,
that's
just
what
else
know
who
is
that
quarter
panels
at
Cisco.
F
The
server-side
key
generation
was
brought
in
for
the
RPG
I
work
because
they
were
doing
the
distribution.
Sorry
is
that
better,
okay,
the
server
side
key
generation
was
brought
in
for
the
RPG
I
worked
because
they
were
doing
distribution
of
the
keys
and
the
method
they
were
using
to
Brian
the
method
they
were
using
to
distribute
the
public
key
information.
I've
had
a
24
hour
lag
or
something
like
that.
So
the
way
they
wanted
to
do
that
was
to
bring
up
a
replacement
router
and
they
wanted
to
be
able
to
distribute
the
key.
D
Any
other
remarks:
no,
then
there
are
some
things
we
want
to
do,
putting
in
some
operational
parameter,
values
which
are
still
open
here,
also
how
to
do
the
server
key
generation,
how
to
insert
to
implement
that
and
explain
the
again
for
the
HTTP
coop
or
if
you
like,
the
eesti
are
a
how
to
do
how
the
trust
relations
will
exist.
So
that
has
to
be
explained
in
more
detail.
We
think
that
you
can
do
all
that
before
ITF
Hamilton.
B
D
B
That's
good
because,
even
though
it's
a
very
simplistic
document,
because
it
just
registers
a
value
but
doesn't
mean
that
it
doesn't
think
yes
yeah
the
other
things,
because
there's
an
interest
to
use
some
of
that
basic
functionality
in
deployments
today,
and
so
it's
better
to
get
something
rolling
out
and
into
the
deployments
rather
than
waiting
for
inclusion
of
sort
of
some
more
esoteric
features.
B
D
D
For
people
who
want
to
look
at
it,
this
is
the
diagram
produced
by
Michael,
which
tells
you
the
different
environments
in
which
Biscay
is
used
and
what's
kind
of
voucher
she
may
use
dun
dun
is
Jason
or
in
seaboard.
If
you
want
at
cetera,
so
I
really
enjoy
encourage
you
to
look
at
it.
It
is
very
interesting
and
that's
all.
G
Okay,
hello,
everyone
I'm
your
own
cylinder
from
Erickson
and
I'm,
going
to
talk
about
an
update
of
a
draft
of
another
name,
so
weary
written
a
draft
called
the
ei
LS,
the
enrollment,
using
application
layer,
security
and
the
content
of
this
new
draft
is
essentially
described
by
the
title:
we're
protecting
ESD
payloads
using
OS
core.
He
is
the
OS
core.
So
in
the
virtual
interim
meeting
second
virtual
entry
meeting
last
fall,
we
discussed
the
different
enrollment
drafts.
G
Another
difference
is
the
discovery.
So,
while
the
discovery
is
the
same,
actually,
how
indicate
support
for
all
score?
Is
it
slightly
different?
So
there
is
an
attribute
defined
in
the
OS
core
draft
and
also
a
proxying
I
mean
you
could
say
it's
both
similar
and
different.
You
could
do
proxying
in
the
same
way
that
you
do
hop-by-hop
from
the
SD
client
to
a
a
cooperate,
HTTP
proxy
and
from
the
proxy
to
the
CA,
or
you
could
do
it
end
to
end
from
from
HTTP
from
SD
server
to
SD
client.
G
H
H
So
I'm
going
to
swat
three
flies
with
one
stroke,
I'm
going
to
talk
about
three
different
drafts
in
one
presentation.
The
first
one
is
the
OAuth
Alf
draft,
which
I'm
going
to
call
the
framework
in
order
to
not
get
a
knot
in
my
time.
The
second
one
is
the
detail.
S
authorized,
which
I
called
the
de
Calais
profile
of
the
framework
and
the
third
one
is
the
score
profile
of
the
framework.
H
Thank
you
so
updates.
Last
ITF
you
saw
version
0h.
We
did
two
updates
and
in
the
next
few
days,
I'm
going
to
upload
a
third
one
thanks
to
Jim
who
found
a
few
errors
that
escaped
me
and
my
co-authors
really
vigilance.
What
we
did
was
we
went
through
the
Ayane
section,
which
was
a
mess
and
unmess
tit.
Hopefully,
then,
someone
I
think
also
Jim
noticed
that
the
scope
claim
was
defined
as
a
string,
and
you
might
want
to
have
that
as
a
byte
array
as
well.
H
If
you
have
contact
encoding,
so
we
changed
that
to
allow
that
then
someone
I,
think
Eric
or
Samuel
introduced
default
names
for
the
inter
speck
and
token
endpoints,
and
we
remove
the
client
token
design
after
discussion
on
the
mailing
list,
which
you
probably
are
aware
of,
or
most
of
you
are
so
we
are
thinking
whether
that
should
go
into
a
separate
draft
or
not.
If
there
is
interest
in
the
working
group
in
that
work,
I
won't
do
it
just
for
sure
I
mean
if
someone
is
interested.
H
I
am
happy
to
do
it,
but
I'm
not
going
to
do
it,
just
let
it
die.
And
finally,
Hannes
did
some
work
on
clarifying
the
possible
use
of
HTTP
instead
of
coop.
It
was
allowed
since
many
versions
back,
but
it
wasn't
100%
clear
and
there
were
a
few
inconsistencies
in
the
texts
from
an
older
version
where
we
just
talked
about
coop.
So
Hans
did
a
few
updates,
and
now
it
should
be
perfectly
clear
that
if
your
use
case
is
more
suited
for
HTTP,
you
can
use
a
space
with
HTTP
as
a
transport
protocol.
H
H
H
We
did
clarify
how
the
client
detects
whether
this
profile
is
using
the
pre
shared
key
or
the
raw
public
key
mode.
It
wasn't
hundred
percent
clear.
We
got
a
review
comment.
All
have
added
some
text
that
clarifies
how
this
is
supposed
to
happen.
Then
there
was
some
parts
of
how
the
PSK
identity
is
used
in
the
PSK
case,
and
we
did
clean
that
part
up.
So
basically,
what
the
resource
server
suspected
to
do
is
if
it
gets
a
PSK
identity
in
the
TLS
handshake
it
is
to
tribe.
That
is
a
key
identifier.
H
First
of
a
key
it
already
knows,
and
if
that
fails,
then
it
should
check
if
the
Pisgah
identity
is
actually
an
access
token
containing
a
key.
So
that
wasn't
hundred
percent
clear
in
the
previous
versions,
and
we
clarified
that
then
much
to
my
distress,
I,
might
add
Olaf
added
the
requirement
of
supporting
the
add
curves
in
raw
public
key
mode
and
I.
Currently
don't
have
a
library
that
supports
that
so
I'm
a
bit
distressed
by
that,
but
it
will
be
solved
eventually.
B
One
honest
yeah
I'm,
not
while
I
like
all
this
work
on
curve
to
509
I,
think
it's
a
little
bit
a
rush
to
mandate
it
right
away,
because
all
the
other
documents
still
say
that
we
mandatory
to
support
this
debate.
Miss
be
2:56,
r1
curve
and
maybe
maybe
have
that
as
a
option
would
be
appropriate,
but
not
the
demanded
iteration,
because
that
would
also
be
an
issue
for.
H
B
I
B
So
in
1.3
it
talks
about
same
as
1.2.
It's
of
talks
about
those
are
sort
of
the
recommendations
for
the
web
space
and
asked
for,
and
maybe
other
application
profiles
and
that's
what
we
did
with
1.2
in
this
DTLS
TLS
IOT
profile,
thomas.
I
don't
know
if
it's
here
and
I
submitted
the
document
first
version
in
for
the
for
such
a
profile
for
1.3,
where
we
essentially
mirror
what
we
said
for
1.2
there.
He
talks
about
the
number
of
algorithms
which
I
haven't
yet
seen
widely
implemented
in
in
in
various
embedded
devices.
So
it
did.
B
A
K
B
And
yeah
understand
here
the
ambition,
but
it
would
be
sad.
If
then,
none
of
the
implementations
actually
support
even
comply
to
the
specification,
so
maybe
having
some
transition
phase
like
he,
you
just
read
for
the
TLS
one
that
sweet
face.
That
would
probably
be
a
good
idea.
There's
also
when
we
talk
about
AES
versus
the
cha-cha
goalie
and
that
falls
into
the
same
category.
H
H
L
So
after
about
five
years,
it's
maybe
time
to
revisit
that
and
I
would
expect
that
we
want
to
do
a
combined
effort
between
all
the
working
groups
that
that
actually
have
a
tribulus
game
on
doing
the
next
set
of
crypto
rivers
that
we
recommend
and,
of
course
behind
the
horizon.
There's
also
the
whole
idea
of
going
to
catch
act
based
mechanisms
for
the
symmetric
part,
so
that
might
be
another
disturbance
there
that
we
might
experience
in
in
that
space.
L
So
maybe
the
whole
concept
of
mandatory
to
implement
is
a
bit
less
useful
in
in
this
environment
than
it
is
in
other
environments,
and
so
we
probably
want
to
modulate
this
little
bit.
Based
on
this
observation,
but
again
not
more
importantly,
we
should
start
a
concerted
approach
to
revisit
the
algorithms
that
we
use
as
mandatory
to
implement
in
all
those
documents,
including
seven
through
five,
and
we
probably
want
to
do
a
kernel
like
process
for
doing
in
us.
I
Olaf
Bergman
a
completely
second
but
Carson
just
said,
and
it's
there
are
open
source
implementations
of
the
55:19
curve.
So
you
have
code
to
look
at
and
I've
been
told
that
it's
even
easier
to
implement
correctly.
Then
the
256
curve
is
so
from
from
my
point
of
view,
pretty
much
makes
sense
to
start
moving
to
that
curve.
Now,
I.
M
And
I
completely
agree,
I'm
working
on
a
TLS
stack
and
it
takes
some
time
to
integrate
these
features
so
personally,
I'm
a
big
fan
of
this
curve
and
true
it's
easier
to
implement
correctly
than
other
curves.
But
while
these
needs
to
be
newly
implemented,
other
curves
have
been
already
implemented
in
many
many
Tila
stacks
and
being
tested
both
in
practice
and
the
test
systems
for
years.
So.
M
Which
one
would
be
best
and
which
one
is
more
accessible?
That
is
a
good
question,
and
what
is
our
goal
with
mandating
this
curve
providing
security
yeah?
Then
it's
achieved
and
it's
good,
but
it
can
be
a
barrier
to
adapting
the
standard
because
IOT
devices
usually
armed
the
long
tail
and
and
it
takes
much
more
time
for
them
to
that
new
algorithm
sends
new
profiles
like
this.
Thank
you.
H
Yes,
it
would
be
good
if
we
could
make
a
decision
on
that
from
the
lists
rather
shoot
so
that
we
can
adopt
our
implementations.
Adapt
I
mean
our
implementations
accordingly.
So,
let's
not
forget
about
that
next
point:
we
made
some
clarifications
in
appendix
now
related
to
Appendix
C
of
the
framework.
Appendix
C
of
the
framework
basically
summarizes
all
the
requirements
that
the
framework
makes
on
profiles
and
it
turned
out.
Some
of
these
requirements
were
not
clearly
represented
in
the
detail
as
profiles,
so
we
made
some
updates
to
clarify
which
parts
fulfill
which
requirements
yes,
Carsten,.
L
L
L
K
K
H
Yes,
next
one
is
a
placeholder
that
remained
a
placeholder
were
planning
to
do
some
plug
testing,
but
I
arrived
late
and
we
had
other
things
that
we
needed
to
do
so.
We
plan
during
the
week
to
plug
together
a
few
implementations
and
see
what
happens.
There
are
I,
think
three
implementations
present
in
the
room
and
there
is
a
fourth
one
which
will
come
to
us
at
ITF,
102
I'm,
going
to
talk
about
those
in
a
moment
next
steps.
Well,
we
need
to
gather
more
implementation
experience.
H
Obviously,
we
have
a
number
of
implementations
that
interoperate
well
with
themselves
and
we
need
to
check
how
they
interoperate
with
other
implementations.
That's
what
we're
planning
to
do.
We
want
to
add
examples
of
how
the
different
parts
of
this
profile
are
planned
to
look
like,
and
we
need
more
reviews.
We've
had
a
review
with
all
correctly
was
it
from
you
Jim?
Yes,
so
more
reviews,
please,
and
if
volunteers.
H
H
H
The
authorization
server
and
here
I
discovered
that
we
hadn't
mandated
that
the
token
was
to
be
encrypted
and
in
the
since
score,
is
a
pre
shared
key
profile,
you're
going
to
be
sending
a
pre
shared
key
in
the
token
to
the
resource
server,
and
you
better
not
want
that
to
be
visible.
So
I
added
a
sentence
that
if
you
send
a
CCW
T,
you
need
to
have
it
encrypted
so
that
listener
on
the
line
doesn't
capture
the
secret
key
next
thing
he
turns
out.
H
Even
here,
it
wasn't
completely
clear
how
the
proof
of
possession
was
supposed
to
happen.
Basically,
it's
implicit
because
you
generate
an
or
score
context
from
the
confirmation
key
and
then,
if
you
can
decrypt
the
message,
then
you
obviously
have
the
right
secret
key.
So
you
can
prove
that
you
have
that
by
just
being
able
to
read
those
core
messages,
we
added
some
security
considerations.
H
It's
a
first
version,
so
this
one
probably
needs
to
go
through
a
number
of
reviews
and
revisions
and
I
added
a
long
section
with
Ayana
considerations
and
given
my
track
record
on
messing
those
up,
we
would
also
need
reviews
on
this
document,
so
people
who
feel
even
more
motivated
go
ahead.
Read
that
it's
not
a
long
draught.
Actually,
it
shouldn't
take
you
too
long
and
provide
us
comments,
and
that
leads
me
to
one
more
open
item.
H
This
is
an
old
item
raised
by
Mike
Jones,
who
asked
us
in
his
very,
very
thorough
review
how
this
related
to
the
token
binding
work
at
a
Walt
and
I
kind
of
tried
to
throw
the
question
back
at
him
because
I
didn't
know
token
binding
and
E
is
at
least
involved.
It's
not
a
co-author
right.
So
I
would
also
like
to
know
how
that
is
related,
any
volunteers,
from
a
wealth
to
help
us
work
that
out.
I
can
talk
to
you
if
you
want
dear
Mike,
but
anyone
else
is
welcome
as
in
generating
hands.
N
H
H
There
was
another
point
that
I
was
thinking
about
and
I
missed
the
meeting.
So
that's
big
bad
of
me
to
ask
that
question,
but
we
had
a
meeting
with
ocf
who
also
have
an
access
control
mechanism
in
their
standards.
Draft
and
I
was
wondering
what
what
conclusion
we
came
we
want
to
have
or
do
we
have
any
relationship
with
ocf
anyone.
H
O
Oh
yes,
number,
not
speaking
for
the
house,
yet
there's
a
meeting
that
we
have
on
friday,
which
I
think
is
what
person's
gonna
get
them
say
to,
and
this
would
be
a
great
question
for
us
to
ask
at
that
meeting,
and
some
of
us
are
going
to
be
at
that
meeting.
So
in
frog,
we're
flying
down
there
on
friday
and
there's
a
joint
thing
to
thing.
O
Research
group,
ocf,
w3c,
meeting
that's
joint
on
friday
afternoon
and
the
purpose
is
to
coordinate
what
can
be
used
across
stos,
and
so
we
can
put
that
on
put
this
on
that
particular
list,
and
so
those
of
us
that
are
in
the
room
that
can
be
there
has
a
there's
at
least
three
of
us,
probably
more
in
this
room.
That
will
be
there,
and
so
we
can
put
this
on
our
list.
Great
great.
L
So
we
are
doing
these
coordination
meetings
with
ocf
approximately
on
a
half
year
Karen's
right
now
and
at
the
last
meeting
we
decided
there
were
some
issues
that
actually
would
motivate
having
interim
phone
conferences
and
the
first
one
we
identified
was
the
relationship
between
the
a
security
work
and
the
ocf
the
security
work.
So
we
started
looking
at
that
in
in
that
phone
conference,
but
I
wouldn't
say
that
that
we
came
to
a
conclusion
you.
L
H
B
Think
I
think
I
personally
think
it
would
be
a
good
idea
to
start
with
a
working
group.
Last
call
not
only
because
of
the
implementations
that
you
had
listed
up
there
and
the
intro
testing
this
week
is
a
little
bit
too
ambitious,
in
my
opinion,
just
coming
from
two
days
of
packet
on
and
and
full
IETF
week
schedule.
B
But
you
don't
know
what
me
and
Jim
are
capable
of
on
your
board.
Let's
see
yes,
ambitions
are
big
and
that's
good,
but
at
the
workshop
our
security
workshop
last
week,
I
also
mentioned
that
we
have
now
released
a
product
implementation
of
of
a
sauce
which
we
call
secure
device
access
and
you
can
find
the
slides
and
some
material
and
pointers
to
the
documentation
in
in
in
that
deck,
and
so
that
would
be
I
think
we
need
more
more
products
in
that
space.
B
H
Great
that
sign
kind
of
escaped
my
attention.
Sorry,
for
anyway,
we're
doing
going
to
do
some
interrupt
testing,
which
is
basically
we're
going
to
plug
together
two
or
three
implementations
and
see
how
they
break
this
week,
sometime
between
the
meetings
and
so
there's
going
to
be,
hopefully
a
bigger
event
at
ITF,
102
I
know
of
four
implementations
that
are
going
to
be
present
at
ITF
102
and
since
Hannes
told
us
this,
the
fifth
one
that
we
can
add
them.
Oops
add
them
to
the
list
here.
H
There's
one
from
us
right
six!
That's
me,
there
is
one
from
Olaf
you
Ramon,
he
said,
I
University
of
Bremen
is
a
tie.
Jim
chard
has
some
code
on
that,
and
then
there
is
the
sei
lab
at
Carnegie
Mellon
University,
who
have
a
constrained
implementation,
which
is
great
because
I
don't
know
if
yeah
olaf's
is
probably
also
a
constrained
one,
but
mine
is
definitely
not
constrained
and
Jim's
I
don't
know
anyway.
H
This
is
going
to
happen.
Yeah.
One
more
question
just
came
to
mind.
I
should
have
taken
that
earlier.
When
I
was
talking
about
the
progress
of
the
framework,
we
removed
the
client
token
and
Hannes,
you
promised
us
a
paper
where
you
had
analyzed
the
security
of
that
approach.
I
have
still
not
seen
that
paper
yeah.
B
This
is
funny
because
you're
not
carefully
watching
the
our
security
workshop.
It's
actually
published
here,
along
with
many
other
papers,
which
I
think
would
be
worthwhile
to
read
and
yeah.
In
fact,
I've
actually
encouraged
this
community
here
to
participate
the
workshop
for
me,
it's
always
useful
to
get
in
touch
with
those
guys,
researchers
who
are
doing
formal
analysis
and
you.
B
G
G
What
you
want
to
call
it,
but
it
basically
is
the
information
going
to
the
client
about
what
it
is
supposed
to
do
and
keys
for
for
doing
that,
so
I
think
that
function.
Basically,
it's
part
of
this,
this
greater
work
scheme
of
things
which
is
covered
in
the
actor's
draft,
but
only
a
specific
case
of
that.
G
How
do
you
actually
so
concrete
example
is
if
you
look
at
the
group
communication,
when
you
authorize
keys
for
group
communication,
then
you
give
typically
rights
for
one
device
to
access
another
device
in
the
group,
but
you
also
would
like
to
have
instructions
for
the
requesting
device
which
other
devices
a
mine
entitled
to
to
contact
which
resources
and
other
devices
were
impacted
to
contact,
and
that
is
not
covered
in
the
framework
today,
and
it
was
one
aspect
of
that
was
covered
in
the
client.
Talk.
H
Q
Q
So
during
last
three
meetings,
we
presented
two
different
drafts
me
and
Marco.
So
one
the
one
about
co-op
pub/sub
is
profile
for
group
king
of
pub/sub
scenario
and
the
oscar
up
joining
joining.
Is
a
group
called
using
no
score,
so
we
got
some
feedback
from
the
working
group
that
about
the
military
similarities
of
those
two
drugs
and
and
so
we
try
to
create
one
document
that
describes
the
similarities,
and
this
is
this
document.
Q
So
this
is
an
overview
of
the
participants
in
in
this
new
draft.
So
we
have
a
client
who
is
the
node
that
is
trying
to
join
the
group
communication.
Das
is
the
same
as
in
the
ACE
framework,
and
we
have
a
key
distribution
center
that
has
the
role
to
just
distribute
the
group
key
material.
The
dispatcher
is
the
note
that
dispatches
to
the
messages
to
the
group
members
and,
for
example,
the
co-op
pub/sub,
it
can
be
the
broker
or
it
could
implicit,
so
it
could
be.
For
example,
a
multicast
IP
address.
Q
Q
Then
we
define
a
new
set
of
messages
to
actually
request
key
distribution
to
the
key
distribution
center.
So
while
this
first
phase
is
defined-
and
it's
very
specific
to
what
profile
you
use,
then
this
one
is
currently
not
existing
in
ace.
So
this
we
try
to
use
the
same
semantics,
but
this
is
new
messages.
Q
So
these
are
the
details
about
what
are
the
what
messages?
What
is
the
format
of
the
messages
so
for
the
authorization
request
response?
This
is
taken
from
the
ACE
again.
The
request
must
contain
this
grantee
parameter
and
may
contain
a
set
of
other
parameters,
and
we
specified
in
this
document
what
each
parameter
contains.
Q
So,
for
example,
the
scope
is
supposed
to
contain
the
group
ID
or
the
topic
or
something
identifying
the
group
communication
and
the
role
of
the
client
role,
meaning,
for
example,
pub/sub
communication
can
be
as
publisher,
also
cragger,
so
we
got
feedback
from
Ludwig
about
use
of
scope.
In
this
way,
the
audience
is
the
KDC,
because
that's
who
the
token
is
supposed
to
go
to
and
yeah
I
just
want
to
underline
that
we
do
a
new
parameter.
That
is
this
github
piece.
Q
This
is
the
client
sends
this
parameter
if
it
wants
to
receive
public
keys
of
other
members
of
the
group
and
then
in
the
response,
we
define
what
what
needs
to
be
sent
so
the
access
token
and
what
does
the
access
token
contain
and
other
other
information
to
establish
secure
communication
with
the
key
distribution
center?
And
then
these
are
the
new
existing
key
distribution
requests
and
response.
Q
So
we
we
define
them
as
being
similar
to
ace
authorization
requests
a
response,
even
though
these
are
not
authorization
requests
the
response,
but
we
still
need
some
parameters
that
are
similar.
So
we
use
the
scope
parameter.
We
use
the
github
keys,
then
we
have
new
parameters,
defined
client,
credential,
public
keys,
red
paw
and
group
policies,
management,
key
material,
etc.
So
we
define
exactly
what
these
messages
look
like
and
then
group
communication
have
to
specify
which
of
these
parameters
are
actually
used.
Q
H
Q
H
Q
H
L
Q
So
the
KDC
can
be
also
key
management
node,
so
it
can
store
and
then
distribute
the
public
keys
of
all
the
joining
nodes.
So
this
is
each
document
using
these
drafts
should
or
must
specify
if
the
KDC
is
also
managing
the
public
keys,
and
this
parameter
is
there
to
allow
for
the
joining
node
to
actually
request
the
public
keys
if
the
KDC
is
storing
public
use
of
all
the
members
of
the
group.
L
Yeah
but
again,
what
is
what
is
the
claim
about
these
public
keys?
So
apparently,
this
is
about
a
group,
so
this
group
must
exist
as
a
concept
somewhere
and
those
public
keys
could
be
used
for
for
data
original
fabrication
and
they
could
be
used
for
targeted
encryption,
different
security
properties
you
want
to
have
here.
These
could
be
published,
subscriber
keys,
okay,.
Q
Q
Maybe
we
can
ask
the
questions
later
so,
just
to
remind
this
is
now
version
zero
to
at
least
was
percent
in
ATF
98,
the
first
time
so
I
added
some
slides
from
there
just
to
remind
you.
What
is
the
coop
pub/sub
architecture
and
what
are
the
roles
of
T
of
T
endpoints
there
are
or
the
nodes
and
the
participants
in
in
destruct.
So
the
update
to
destruct
is
that
it
is
now
coherent
with
this
new
draft.
Q
So
just
a
reminder
is
we
have
two
authorization
server,
one,
a
s1
and
s2
a
swan
defines
what
endpoints
are
allowed
to
publish
to
topic
a
on
broker
B,
so
it's
access
to
the
broker
and
a
steward.
What
endpoints
are
allowed
to
access
topic
a
so?
There
are
pre-existing
security
association
between
publishers
and
subscribers
to
both
a
s1
and
s2,
and
the
goal
is
to
set
up
security
association
between
publishing
broker
and
the
second
one
is
between
publishing
subscribers.
Q
So
this
is
the
overview
and
it's
compared
to
the
other
graph
that
you
see
so
before.
So
we
have
two
different
AAS
here.
We
have
a
s1
which
corresponds
to
a
s
in
the
other
draft
and
then
a
s2
is
actually
one
node
that
has
both
functions
of
AES
and
key
distribution
center
from
the
other
draft.
So
this
is
how
this
profile
define
defines
these
nodes.
Then
we
have
a
client
that
can
be
either
a
publisher
or
want
to
be
publisher
or
subscriber
dispatcher
is
the
broker
than
the
group
members.
Q
Q
So
in
this
case
the
same
no,
they
spot
a
s
and
key
distribution
center,
which
means
that
there
is
no
need
to
do
the
token
post
and
we
can
combine
authorization
request
and
key
distribution
requests.
So
we
take
the
parts
of
these
messages
that
we
need
and
for
subscriber
there
so
as
defined
right
now.
There
is
no
need
to
to.
Q
S
Guess
it's
just
a
comment.
This
is
Eve
mailer
I,
think
where
people
were
sort
of
I
was
one
of
them
shouting,
that's
an
RS,
not
an
ass
before
this
is
maybe
a
clarifying
concept
that
may
help.
People,
including
me,
understand
your
diagram
mm-hmm,
because
I
think
what
you've
got
is
you've
defined
a
standardized
interface
for
the
KDC,
which
is
a
function
of
an
ass
but
you've
protected
it.
So
what
you've
got
is
you've
got
a
standardized
interface
for
a
function
of
your
AAS
that
you've
both
protected
and
thus
that
KDC
there
is.
Q
S
Q
S
Q
S
Q
So,
yes,
this
defines
how
they're
coming.
Finally,
the
third
face
that
is
defining
this
document
is
how
the
coefficients
protected.
So
there
is
secure
channel
between
client
and
broker,
and
then
there
is
also
messages
protected
with
application
layer,
security
between
publisher
and
old
members,
so
su
progress
and
publishers.
Q
So
the
last
two
slides
are
about
how
these
messages
match
to
the
key
operation
in
group
con
draft.
So
so
we
have
only
two
messages,
so
these
are
the
authorization
request,
plus
key
distribution,
request
and
authorization
response,
kreski
solution
response
that
are
sent
from
client
to
a
s2,
and
these
are
the
details
and
yes,
I'm
not
going
to
go
through
all
the
details,
because
you
can
read
the
draft
and
come
back
with
comments
for
that.
Q
But
that
of
course
depends
if
node
is
a
publisher
or
a
subscriber
if
it's
gonna
request
public
keys
of
the
other
members
or
not
and
yeah.
This
is
the
same
content
that
was
in
the
previous
just
adapted
to
this
format
and
yeah.
That's
it
so
we
got
I
just
want
to
say
we
got
quite
some
support
for
the
this
profile
and
also
for
the
profile.
That
is
coming
after
me
and
and
yeah.
We
answered
the
request
to
make
this
more
general
format,
content
by
splitting
or
creating
this
graph.
A
As
always,
it's
good
to
get
more
people
reading
the
documents
might
have
pause.
If
you
have
blue
sheets
next
to
you,
could
you
just
hold
them
up
in
the
air
for
a
little
bit,
I
think
there
are
a
couple
people
who
came
in
late
and
still
need
to
sign
the
blue
sheets.
Do
you
have
a
blue
sheet
sitting
next
to
you,
anyone.
T
My
six,
this
is
another
update
to
the
draft
describing
how
to
join
groups
where
communication
is
protected
with
a
score
again
using
the
ACE
framework
in
its
profiles
and
its
update
especially
followed
direct
actions.
We
agreed
to
take
four
especially
out
of
discussions
with
Jim,
thanks
for
that,
as
you
can
guess
mostly
related
to
the
draft
that
Francesca
presented
before
so,
we
needed
to
define
the
exact
content
of
messages
exchanged
between
the
participants
in
the
protocol.
T
Of
course,
along
with
the
general
head
of
a
guideline,
we
already
provided
in
the
main
core
document
describing
core
group
communication
and,
of
course
we
need
to
address
the
similarities
with
the
pub/sub
profile
because
they
had
a
partial
overlapping
and
we
didn't
like
to
come
to
redefine
or
implement
the
same
form
as
multiple
times.
So
as
a
result,
we
produced
that
join
document,
a
ski
group
calm
and
in
this
document
essentially
now
we
have
redefined
all
the
protocol
steps
specifying
how
the
general
message
template
from
a
ski
group.
Calm
can
be
instance.
T
It
is
specifically
for
for
this
scenario
and
with
reference
especially
to
the
workflow
we
saw
before
here.
The
group
manager
in
charge
of
the
oscar
group
acts
as
a
KABC
in
the
generic
model,
and
it
is
a
resource
server
here
and
instead
we
don't
have
an
actual
participant
node
acting
as
dispatcher,
so
especially
messages
addressed.
The
whole
group
are
just
sent
to
a
multicast
IP
address.
T
So
essentially,
we
went
through
all
the
protocol
steps
and
the
fine
parameter
per
per
starting
from
the
generic
model.
How
each
parameter
is
field
according
to
possibly
structure,
and
especially
the
scope
parameter
in
the
authorization
request
is
used
by
the
joining
node
acting
as
client
specify,
mostly
the
identifier
of
the
group.
It
intends
to
join
and
the
role
or
set
of
roles
that
you
would
like
to
have
in
the
group.
T
The
audience
parameter
instead
points
at
the
group
manager,
essentially
its
address
and
get
pop
keys
here
it
is
used
and
we
define
how
again,
in
relation
with
the
main
core
document,
the
group
manager
can
optionally
be
configured
also
to
act
as
repository
of
public
keys
of
group
members
then
use
the
centroid
to
produce
digital
signatures
of
messages
sent
to
the
group.
So
in
that
case
the
joining
node
can
express
the
signal
that
it
wants
to
have
the
public
keys
of
the
members
of
the
group
at
joining
time.
T
T
In
this
case,
then,
the
protocol
continues,
of
course,
with
a
token
post
on
the
group
manager,
the
establishment
of
a
secure
channel
if
one
is
not
already
available
and
then
again,
the
use
of
get
get
a
key
parameter
in
case
of
retrieving
a
public
key
nodes
of
group.
Members
from
the
jury
know
that
joining
time
here
we
have
a
number
of
corner
case
that
are,
of
course,
better
document
in
the
graft
in
the
draft
and
already
in
the
first
place
in
the
main
core
document.
T
This
is
the
most
important
part
in
the
end.
It's
how
the
journey
node
is
actually
provided
with
a
key
material
that
it
requires
to
participate.
The
secure
communication
in
the
group,
so
most
of
it,
is
part
of
the
structure
key
parameter
where
most
of
parameters
come
already
from
the
cosy
RFC
and
others.
We
are
reusing
from
the
oscar
profile
vase.
Essentially,
we
are
introducing
a
new
parameter
CSL,
where
the
group
measure
essentially
specifies
the
country
signature
algorithm
used
within
the
group
to
produce
country
signature
of
messages.
T
Then
the
message
continues
with,
if
requested,
the
public
keys
of
group
members
and
a
list
of
group
policies
possibly
applied
in
the
group
and
relevant
ones.
Better
documented,
of
course,
in
the
core
document,
are
the
first
synchronized
sequence,
numbers
of
multicast
URLs
in
the
group
or
the
specific
working
protocol
used
to
revoke
and
redistribute
keys
in
the
group
and
related
to
that
particular
policy.
T
So,
to
conclude,
this
is
now
aligned
with
a
new
document
describing
the
general
format
of
key
provisioning
messages
to
support
and
enable
group
communication.
It's
also,
of
course,
along
with
the
intent
and
general
guideline
we
already
have
in
the
main
core
document
describing
oscar
group
comm
and
speaking
about
also
synchronization
between
multiple
venues.
Right
now,
this
approaches
the
recommended
one
to
join
a
group,
the
main
core
document.
In
the
case,
this
is
a
recommended
one
out
of
a
more
generic
description.
T
So
I
wonder
if
we
should
consider
this
as
something
more
than
recommended,
one
as
the
way
or
instead
keep
room
for
possible
alternative
approaches,
so
keeping
also
generic
description
at
a
high
level
as
well.
But
we
can
take
that
letter
I
just
that
this
discipline
question
other
than
that.
This
document
got
support
already
in
the
past
and
it
was
labeled
as
high
priority
at
the
a
sintering
meeting
and
the
last
year
that
the
big
thing
missing
was
especially
having
this
alignment
with
generic
message
format
description.
G
In
London,
so
what
we
have
seen
is
an
interest
to
work
on
or
to
produce
standards
around
group
communication
or
four
simple
IOT
devices,
and
in
that
context
the
this
draft
was
pointed
out
as
one
way
of
of
solving
that
so
I
think
there
are
people
here
from
fair
hair
Alliance,
who
could
add
more
more
material
to
that.
But
they
have
definitely
shown
an
interest
in
this
draft
and
then
I
suppose.
That
would
also
imply
something
I'm
depending
draft
as
well.
D
Peter
fonda
stock
I'd
like
to
express
my
support
for
this
document.
I
think
the
intention
is
good
that,
like
accurate,
it
gives
enroll
and
possibility
to
do
cop
communication
so
which
is
very
nice
and
people
really
forward
to
that.
I
read
an
earlier
version
of
the
Daath
I
have
not
read
the
line
version
I'm
very
happy
that
you
do
an
alignment,
less
standards
which
the
same
purpose
is
very
good.
So
yes
I'm
a
favor
of
this
map,
but
I'd
like
to
reread
it
once
more.
Yes,
okay,
thanks.
N
G
So
the
chairs,
written
really
haven't,
didn't,
have
a
good
imagination
for
speakers.
Here's
the
second
out
of
three
presentations,
I'm
gonna,
deliver
today.
So
this
is
about
key
exchange
for
all
score
and
Oscar,
as
you
know,
is,
is
becoming
more
and
more
used
is
adopted
by
various
working
groups
and
in
the
IDF
and
SDOs
and
and
industry
consortium.
G
Now
what
score
depends
on
the
establishment
of
a
strong
master
secret?
So
it's
a
pre-shared
key
pressure.
Key
setting
and
two
alternatives
are
defines
you
could
either
do
the
pre
shared
key
in
in
some
constrained
settings
that
still
a
valid
deployment
or
you
could
use
the
ascore
profile
base
which
we've
been
speaking
about
today.
But
what
is
missing
for
the
scenarios
where
we
need
forward
security
is
a
key
exchange
protocol
and
basically
to
two
alternatives,
have
been
raised
for
how
to
address
key
exchange
for
raw
score,
and
the
alternative.
G
A
here
is
that
we
reuse
the
transport
layer
security
handshake.
So
we
do
some
sort
of
profile
of
TLS
or
DTLS
application
layer
and
there
there
is
no
such
profile
at
the
moment
that
there
are
building
blocks.
So
you
could
either
one
early
example
of
this
is
the
cody
TLS
draft,
which
is
doing
DTLS
over
coop.
G
Another
example
is
the
TLS
or
scorer
draft,
which
is
specifically
addressing
the
parameters
needed
for
a
score.
So
there
are
certain
in
addition
to
the
master
secret.
There
are
two
identifiers
that
needs
to
be
provisioned
and
the
third
option
is
to
look
at
the
things
they're
doing
in
the
Atlas
working
group
that
hummus
announced
previously
today.
G
So
that's
a
TLS
path
for
for
key
exchange
and
the
other
path
is
to
look
at
a
compact
key
exchange
protocol
that
we
have
been
developing
here
in
ace.
So
it's
built
on
C,
bore
and
cozy
and
simple
or
high-level
comparison
between
the
two
drafts
between
the
two
proposals.
So
TLS,
obviously
you
know,
is
a
built
on
a
well-known
theoretical
cryptographic.
Protocol
called
Sigma
I,
which
is
implemented
in
terms
of
TLS
and
data
structures.
G
Erik
is
also
using
the
same
theoretical
protocol,
but
it's
implemented
instead,
instead
in
in
terms
of
Seaborg,
cozy
and
and
co-op,
which
is
reducing
the
Earth's
core
primitives.
So
ad
hoc
is
much
more
limited
functionality
protocol.
So
you
could
say
it's
a
simple
protocol.
He
produces
smaller
messages,
as
is
shown
in
the
next
slide,
but
the
main
difference
between
TLS
and
Erik,
of
course,
is
the
amount
of
thorough
the
amount
of
security
analysis
that
has
been
behind.
G
So
that's,
there
is
some
still
some
some
some
things
that
are
being
analyzed
in
the
setting
of
TLS,
but
mainly
this
is
a
very
analyzed
protocol,
whereas
for
faradic
we
still,
we
have
just
started
the
formal
verification
and
yeah.
So
looking
at
message
sizes,
there
is
a
here's,
a
simple
comparison
between
looking
at
a
dsk
authenticated
diffie-hellman,
which
is
the
brown
or
orange
in
the
case
of
TLS
and
ad
hoc
and
the
symmetric
key
authenticated
diffie-hellman
in
the
case
of
TLS,
an
ad
hoc.
G
And
that's
the
second
sub
column
in
each
in
each
of
the
columns
is
illustrating
one
example.
So
this
we've
taken,
these
are
numbers
from
60.
So
it's
an
example
of
how
many
bytes
you
could
carry
in
one
frame.
So
these
are
making
certain
assumptions
on
the
the
the
actual
overhead
used
on
the
link
layer
in
terms
of
15.4
6lowpan
and
the
security
on
link
layer,
so
with
75
bytes.
As
an
example.
G
These
handshake
messages
are
not
are
then
fragmented
and
those
fragments
are
then
colliding
with
each
other
and
creating
interference
and-
and
you
have
to
sort
of
see
how
long
time
does
it
take
to
get
this
is
up
and
running.
Unfortunately,
we
don't
have
the
simulation
and
they'd
already.
We
will
probably
have
it
in
not
too
long
while,
but
basically
this
there
is.
There
is
a
difference
in
terms
of
of
deployments
and
what
scenarios
you
actually
can
deploy
with
with
the
key
exchange
protocol.
G
So,
and
that
was
basically
the
background.
The
motivation
and
what
I
like
to
hear
is
people's
views
on
how
do
we
progress
the
key
exchange
protocol
for
a
parole
score?
So
we've
seen
that
you
can
make
a
more
lightweight
protocol
than
TLS
definitely,
and
you
can
also
use
one
great
on
with
lower
footprint,
because
you
could
build
it
on
the
same
primitive
sauce
core.
G
An
important
thing
is
the
security
analysis
and
the
issue
we've
had
previously
is
that
people
come
to
us
and
say
yes,
we'd
like
to
make
a
security
analysis
of
a
Red
Hook,
but
they
also
would
like
to
know
how
does
the
IETF
position
itself
with
respect
to
this
new
protocol?
And
if
we
say
that
well,
you
first
have
to
make
the
security
analysis
for
us,
and
then
we
tell
you
if
you're
interested
or
not,
then
they
are
not
as
interested
in
making
the
analysis.
G
So
you
don't
need
to
beforehand
to
prove
it
just
because
you
accept
the
ITF
is
going
to
work
on
this
protocol,
and
the
final
question
from
my
side
is
what,
if
we
don't
want
to
have
a
lightweight
key
exchange
protocol,
what
are
the
consequences
of
that?
Well,
people
deploy
things
without
key
exchange
instead
or
with
what
what
would
be
the
options?
G
U
Michael
Michael
Richardson
I
have
a
couple
points,
but
I'll
just
your
last
one.
First,
the
result
of
not
having
a
lightweight
keep
exchange
protocol
will
be,
pin
zero,
zero
zero
that
we
all
use
for
our
headsets
for
a
great
number
of
consumer
products.
Maybe
there
are
some
other
places
where
that
won't
happen,
but
I'm
skeptical,
but
then
I
wanted
like
to
say
that
I'm
pretty
sure
we
deployed
SSL
two
and
three
without
a
security
analysis
and
IP
1
and
V
2.
That
is
security
analysis.
G
U
It's
no
surprise
that
we
have
to
revise
protocols
because
we
found
bugs
so
to
expect
that
a
protocol
that
goes
out
there
has
no
bugs
is
to
say
that
well,
I
guess
we're
all
running
SSL
3,
not
even
TLS
one
right
and
that's
not
true-
we're
moving
really
hard
to
fix
those
bugs,
and
that's
because
we
got
security
reviews
and
to
say
that
you
have
to
put
the
egg
before
the
horse
before
the
cart
is
silly,
but
I
don't
want
it.
I
want
a
rat
hold
on
this
I
know
it's
your
issue.
U
I
would
like
to
know.
Thank
you
for
posting.
The
the
slide
with
PSK
bite,
sizes
and
I
had
difficulty
reading
it
from
most
my
vision,
but
so
I
wonder,
did
you
did
you
do
an
analysis
with
I'm,
particularly
interested
in
a
situation
where
one
end
one
side
has
a
certificate
and
the
other
one
has
a
raw
public
key
and.
U
G
G
U
U
U
V
V
We
are
using
this
during
the
network
formation
based
on
bootstrapping,
where,
essentially,
this
is
this
results
in
slaughter,
the
loss
axes
and
all
the
nodes
content
before
the
access
to
the
channel
and
the
probability
of
collision
just
raises
exponentially
with
the
number
of
nodes,
and
you
pretty
much
get
1/3
of
bandwidth.
In
the
ideal
case,
a
third
of
you
get
a
throughput
that
is
a
third
of
bandwidth,
indiadee,
located
in
the
ideal
case
with
a
large
number
of
modes
and
to
put
a
figure
on
this.
In
six
distances
around
30
to
40
bytes
per
second.
B
G
V
V
That
were
used
in
four
or
five
artists
organized
so
far
and
to
your
point
about
the
time
that
it
takes
to
bring
this
to
market
I
think
this
is
an
important
differentiator
among
companies.
If,
for
some
companies,
it
takes
several
years
for
other.
If
it
takes
a
couple
of
months,
then
I
mean
you
should
I
appreciate.
B
Your
research
implementations,
but
it
if
you
want
to
get
something
rolled
out
and
I,
think
you
are
downplaying
the
investment
that
you
asking
people
to
do
and
in
understand
that
it
doesn't
take
you
along
to
a
long
time
to
write
the
code
in
six
days.
But
it
takes
us
a
long
time
to
write
solid
security,
implementations
and
what
we've
been
advocating
is
to
reuse
those
because
because
of
all
the
investment
we've
made
and
you
you
want
to
shave
off
a
few
bites
and
then
claimed
it's
a
big
big
drama.
B
If
you,
if
you
add
a
few
bytes
more,
we
have
not
seen
that
if
many
of
our
our
customers,
because
they
even
for
example,
we
had
all
these
optimizations
for
raw
public
keys
and
ppreciate
secret
and
so
on.
And
then
many
companies
still
go
ahead
and
use
certificates
even
fairly
large
certificates,
because
they
they
are
conservative.
They
want
to
use
some
existing
infrastructure,
they
have
a
CIA
infrastructure,
they
want
to
reuse.
B
Of
course,
it
would
be
more
efficient
to
strip
off
all
sorts
of
things,
but
there
are
lots
of
strings
attached,
also
operationally
that
you
need
to
suddenly
change,
and
then
people
are
not
doing
those
going
that
step,
and
so
it
sounds
like.
Oh,
we
really
need
to
do
something.
Otherwise
we
go
back
to
Mike,
Ritz
pincers.
Here
our
example,
but
I.
Don't
think
that
that's
the
reality,
though,.
V
L
Just
moment,
I
completely
agree
that
we
have
to
have
implementations
of
this
and
that
we
have
to
look
for
for
production,
quality
implementation,
so
counting
the
number
of
open-source
implementations.
This
is
interesting,
but
it's
not
the
only
indicator.
We
need
there's.
One
thing
that
I
would
like
to
point
out
here:
TLS
doesn't
currently
do
what
we
need
to
do.
We
need
an
adapter
to
TLS
to
make
it
to
what
we
need
and
I
would
expect
doing.
This
adapter
is
about
the
same
amount
of
work
amount
of
engineering
as
doing
an
hog
in
the
first
place.
B
The
adapter
is
called
key.
Extractor
has
been
around
for
a
long
time
and
if,
like
try
to
implement
it,
then
you
see
yourself
on
how
how
much
work
that
is
and
it
has
been
used.
Key
extractor
has
been
used,
for
example,
DTLS
SRTP,
because
there
has
the
same
model
has
been
followed,
but
I'm
still
waiting
to
see
for
people
to
blow
deploy
or
score
first
and
then
see
how
that
how
that
plays
up.
X
Kaplan
Moriarty
area
director,
so
thank
you
very
much
for
your
work
on
this
and
proving
out
the
message
size
differences,
because
that
was
one
of
the
things
that
you
were
asked
in
previous
conversations.
I,
don't
like
how
much
the
work
had
been
held
up
by
this
prerequisite.
That's
not
normally
applied
to
other
work
being
done.
However,
you
did
this
work,
so
thank
you.
I
do
think
that
there
is
enough
room
in
the
billions
of
devices
in
IOT
for
another
solution
that
fits
different
architectural
constraints
and
device
constraints.
X
So
I
would
personally
like
to
see
this
work
go
forward
in
terms
of
security
proofing.
I
agree
with
what
Michael
said.
I
do
think
there
is
room,
and
if
you
know
certain
vendors
don't
need
this,
because
their
devices
adequately
can
handle
TLS
and
existing
solutions.
That's
great,
but
I
think
there
may
be
spaces
where
this
is
very
important
for
other
architectural
decisions.
So
I
would
like
to
see
this
continue.
G
G
So
today,
we've
already
spoken
about
the
ACE
framework,
the
DTLS
or
score
profile
and
the
keying,
the
last
three
drafts,
and
there
are
two
more
of
a
framework
dependent
protocols.
It's
the
ipsec
profile
and
the
mqtt
profile,
and
the
authors
are
here
if
you're
interested
in
those
drafts,
the
basic
questions
that
I'd
like
to
hand
over
to
the
chairs
to
take
over
the
discussion.
G
I
just
want
to
introduce
the
the
things
I
think
we
could
think
about
in
completing
the
work
in
the
ACE
framework,
and
previously
we
said
we
should
wait
with
progressing
ace
framework
until
we
have
developed
profiles
and
tested
it,
and
that
was
the
already
discussion
previously
whether
we
are
ready
for
moving
on
or
whether
we
need
to
wait
profiling
drop
testing.
There
is
also
the
aspect
of
security
analysis.
There
is
a
publication
or
a
conference
contribution.
G
W
G
And
there
is
also
not
the
other
issue
which
I
mentioned
previously,
but
I
didn't
hear
any
any
response
on.
That's
the
client
authorization
aspects
which
is
not
very
detailed
in
in
the
ACE
framework
and
finally,
what
I
should
do
this
working
group
work
with
this
set
of
documents?
Are
we
going
to
scope
for
a
particular
set
of
targeted
adopted
drafts
which
we
complete
and
then
stop
the
work
or
are
we
remain?
Are
we
open
for
introducing
new
profiles?
H
Sites
on
the
last
point,
short-term
memory
last
point:
I
would
very
much
be
in
favor
of
not
limiting
us
to
the
two
existing
profiles
we
have
adopted
right
now,
because
that's
not
the
idea
we
had
when
we
designed
this
whole
thing
as
a
framework
and
then
profiles
because
yeah
you
could
do
now.
You
could
use
it
a
lesson,
no
score,
and
that
covers
some
use
cases.
H
But,
as
Kathleen
so
eloquently
said,
there
are
billions
of
devices
with
different
use
cases,
and
especially
when
talking
to
industry
contacts
I
have
heard
MQTT
mentioned
a
lot
in
the
IOT
space.
So
that
is
a
profile.
I
definitely
think
we
should
work
on
and
publish/subscribe
feels
pretty
relevant
in
that
context
as
well,
and
there
is
publish/subscribe
working
core,
which
is
basically
the
group
we're
catering
for
so
I
guess
there
is
a
number
of
things.
L
L
This
way
of
doing
things
is
not
not
a
prerequisite
to
using
what
is
called
a
pops
up
profile
here,
because
the
pops
up
profile
really
is
about
getting
the
the
authentication
in
place
for
a
group,
and
the
group
may
actually
be
structured
in
a
completely
different
way
that
the
way
the
group
is
mapped
to
to
respirators
may
be
done
in
a
different
way,
and
we
have
that
we
can
use
multicast.
For
that.
So
I
wouldn't
say
the
the
pops
up
document
is
a
prerequisite
for
for
the
work
here
to
lead
to
a
useful
result.
L
L
So
there
are
various
broker
based
protocols
in
using
the
IOT,
including
AMQP,
but
lots
of
people
think
imputed
here
somehow
important.
So
we
want
to
just
to
write
down
to
show
how
to
solve
the
same
problem
using
existing
coil
primitives.
So
that's
how
it
started
as
a
demonstration
as
a
proof
of
concept
and
then
it
kind
of
well.
We
had
to
made
our
point
and
the
interest
in
actually
if
it
was
I'm,
seeing
some
indications
that
this
is
now
picking
up
again
and
I
think
we
will
have
half
a
year.
J
L
A
So
the
intent
here
was
to
have
a
little
bit
of
open
mic
time
for
people
to
express
opinions
and
of
course,
we
still
have
some
more
time
for
that.
A
little
bit
did
have
a
couple
of
questions
that
it
would
be
good
to
ask
the
working
group
relating
to
ed
Hawk
specifically,
but
I
will
let
Kirsten
talk
again.
First.
L
Okay,
you
just
said
this
is
the
time
to
voice
opinions
when
we
started
the
work
that
finally
led
to
the
ACE
working
group.
We
had
an
idea
of
the
set
of
problems
that
needed
to
be
solved
and
then
in
Hama
I
think
we
agreed
to
use
OAuth
as
one
part
of
solving
this
set
of
problems.
So
I
think
we
have
progressed
pretty
well
with
that
and
I
would
be
in
favor
of
completing
a
first
version
of
that
work.
To
get
back
to
the
rest
of
the
problem
that
we
have
been
trying
to
solve.
L
So
I
wouldn't
say
that
the
framework
document
should
be
the
only
outcome
of
days.
It
should
not
be
the
ACE
framework
to
be
a
source
framework,
and
we
should
do
other
work
to
complete
the
requirements
on
an
authorization
and
authentication
that
we
find
in
the
internet
of
things
now
what
shape
that
typically
takes.
That.
That
depends
a
lot
on
a
point
of
use,
or
we
will
have
to
discuss
that,
and
maybe
the
the
input
that
went
into
the
Yokohama
discussion
also
is
a
little
bit
dated
and
we
have
to
update
it.
B
Couple
of
people
are
talking
about
done
in
the
working
group
closing
the
work
group.
Nobody,
nobody
suggested
that
in
previously
at
least
not
my
understanding,
because
the
framework
is
not
finished,
the
profiles
are
not
finished.
Other
documents
have
work
in
progress,
so
I
don't
know
what
you
guys
are
talking
about
here.
It
would,
however,
going
back
to
what
custom
are
raised
on
on
the
goals
that
were
set
out
early
at
the
beginning.
I
think
it's
always
good
to
do
a
reality
check
after
a
couple
of
years,
because
many
things
have
changed.
B
You
know
like
this
is
not
work
work
in
a
vacuum.
There
are
lots
of
in
the
other
industry
efforts
and
what
we
fought
a
few
years
ago
on
how
sort
of
the
whole
deployment
would
look
like,
obviously
a
little
bit
different
at
this
time
now,
for
example,
I
think
back,
then
we
were
hoping
that
in
the
smart
home
environment
there
would
be
a
lot
of
interest
in
deploying
standardized
solutions
and
it
would
be
very
complicated.
Architectures
came
from
there.
B
A
You
know
those
are
interesting
thoughts,
while
we
have
quite
time
at
the
mic
line.
I
would
like
to
go
back
to
Ed
Hawke,
because
we
did
get
some
very
interesting
numbers
from
the
the
overheads,
but
you
know
just
sort
of
a
as
a
general
prerequisite
before
any
hums
like
to
get
a
sense.
How
many
people
actually
read
the
ad
hoc
document
just
a
show
hands
there,
so
the
number
may
be
15.
A
A
I'd
also
like
to
take
this
chance
to
ask
about
ad
hoc
I
know:
we've
heard
that
there
have
some
business
objections
about
how
taking
on
the
ad
hoc
work
would
be
a
lot
of
work,
and
you
know
there's
been
people
asking
for
things
that
are
not
Katrina
your
say,
but
I'd
very
much
like
to
hear
if
there
are
specific
technical
objections
to
ad
hoc
that
have
not
been
covered
already
today.
So
if
you
do
have
a
technical
objection
to
EDD
Huck,
please
come
to
Mike
now.
B
This
is
Sunnyside.
I
would
be
interested
to
see
the
details
are
posted
to
the
list
specifically
since
the
protocols
offer
different
features.
So
of
course
they
have
different
message.
Sizes
and
I
also
want
to
point
out
that
message.
Size
is
off,
while
it's
often
evening
t-shirts
promoted
as
the
only
sort
of
real
measurement
on
on
performance,
but
there's
actually
other
aspects
as
well.
There's
fresh
size,
there's
the
underlying
performance,
so
I
think
we
should
take
that
into
account
as
well.
B
At
the
to
this
wake
you
up,
I
think
at
the
next
meeting
we
talked
about
emu.
We
talked
about
there
eap-tls
and
you
add,
support
for
that.
Do
IOT
devices
that
connect
to
Wi-Fi
networks
and
then
obviously,
there's
no
co-chairing
possibilities,
or
we
double
the
size
or
at
least
increase
it
substantially
and
so
on
and
so
on.
These
type
of
things
have
to
be
taken
into
account
as
well:
okay,
yeah.
A
B
X
Kathleen
Moriarty
area
directors,
so
I,
don't
think.
We've
heard
enough
serious
technical
objections
and
I
I
just
want
to
confirm
your
next
step
is
to
put
this
out
on
the
list
so
that
we
don't
delay
further
and
we
look
for
all
of
that.
I
just
wanted
to
set
in
the
meeting.
Thank
you,
I
figured.
It
was
your
next
step
yeah.
Thank
you.
G
G
This
is
about
addressing
certain
use
cases
where
we
need
a
key
exchange
protocol
for
all
score
that
is
efficient
for
that
type
of
constraint
deployment,
so,
whereas
this
could
be
painted
as
we
are
going
to
have
double
stacks
everywhere
or
we
going
to
replace
well-proven
protocols.
That's
that's
not
intent
here.
We're
looking
at
the
set
of
use
cases
where
a
profiled
protocol,
which
does
not
have
at
all
the
same
features
as
TLS,
is
doing
the
key
exchange
providing
the
forward
secrecy
for
the
keys
that
we
need.
So
that's
that's.
Essentially
the
proposal.