►
From YouTube: IETF109-EMU-20201120-0500
Description
EMU meeting session at IETF109
2020/11/20 0500
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
B
So
there's
a
couple
links
here,
I
think,
probably
by
this
time
in
the
week
you're
pretty
experienced
with
dealing
with
the
virtual
meeting
tools,
but
here's
some
info,
but
what
you're
probably
really
all
waiting
for
is
the
favorite
notewell
again
you're-
probably
all
familiar
with
this.
But
if
you're
not
please
familiar
yourself
familiarize
yourself
with
the
ietf's
ipr
policies.
B
All
right,
so
we
have
a
pretty
full
agenda.
I
think
we'll
have
enough
time
for
it
this
time,
but
because
we
ran
out
of
time
last
time
we
did
give
a
priority
to
some
of
the
presentations
that
we
were
unable
to
get
to
in.
At
the
last
virtual
meeting
we
have
note
takers,
the
blue
sheets
are
taken
automatically.
We
have
people
monitoring
jabber,
so
is
there
any
bashing
of
the
agenda
that
we'd
like
to?
B
Do
I
mean
we
have
tls
proof
of
knowledge
from
either
owen
or
dan
will
present,
I'm
not
sure
which-
and
we
have
tls
ibs,
we'll
go
through
some
of
the
type
of
rada.
Hopefully,
that
will
not
take
the
whole
time,
but
hopefully
we
can
have
some
good
discussion
on
that,
an
update
for
eep
noob
and
then
a
new
presentation
on
eve
ad
hoc,
any
other
topics.
People
want
to
go
through.
C
C
C
Hopefully
today,
but
I
guess
more
importantly,
we
are
waiting
for
a
review
from
harness.
He
had
promised
that
he
will
go
over
the
document
once
more
and
thank
you,
hannes
already,
for
sending
the
reviews
thus
far
so
yeah
then
epls
with
tls
1.3,
hopefully
will
be
done
by
december.
If
aka,
the
5448
best
document
is
spending
some
synchronization
with
3gpp.
So
we'll
wait
for
that.
C
I
think
yari
and
vesa
who
are
co-authors,
are
also
like
discussing
this
in
3gpp
and
basically
figuring
out
how
how
to
ensure
that
both
the
document
here
in
the
ietf
and
the
specs
in
3gpp
are
are
completely
in
sync
and
don't
leave
something
to
to
be
misunderstood.
So
we
wait
for
a
document
update
on
that
too
and
yeah.
We
had
our
first
rfc
published
between
108
and
109,
which
was
rfc
8940,
and
thanks
to
alan
for
doing
the
work.
E
Yeah
hi
hi
cho,
hi,
mohit
yeah
I've
started
doing
the
review
already
this
week
was
a
little
bit
busy,
but
yeah
thanks
for
the
updates
mohit,
I
definitely
much
better.
The
document
is
much
better
now.
I
think,
from
a
readability
point
of
view,
so
that
only
maybe
knits
here
and
there,
but
nothing
nothing,
really
substantial.
C
B
G
G
Yeah,
perfect,
okay,
so
this
is
tls
proof
of
knowledge,
myself
and
dan
I'll.
Just
give
you
some
background
context.
First,
on
the
wi-fi
alliance
device
provisioning
profile.
So
what
wi-fi
alliance
tpp?
Does
it
defines
how
a
supplicant
bootstrap
keypair
can
be
used
to
bootstrap
the
supplicant
security
against
the
wi-fi
network?
G
Dpp
gives
the
supplicant
to
guarantee
that
it's
connecting
to
a
network
that
knows
its
booster
public
key
and
just
some
information
on
what
this
butcher
public
key.
Is
it's
encoded
using
a
rfc,
5280
subway
public
key
info?
It's
a
rocky
pair.
It
doesn't
necessarily
have
to
be
part
for
pki.
It
may
be
static,
embedded
in
the
supplicant
firmware
printed
on.
It
may
be
delivered
via
printing
on
a
qr
label
included
in
a
bit
of
materials,
etc
or,
alternatively,
the
bootstrap
key
may
be
dynamically
generated
and
displayed
on
the
gui.
G
And
what
this
means
from
a
deployment
perspective
is
that
if
a
device
supports
both
wi-fi
and
wired
networks,
the
same
qr
codes,
the
same
bom
et
cetera,
may
be
used
to
establish
trust
across
both
wi-fi
and
wired
networks
and
just
at
the
very
bottom.
There.
I've
given
an
example
of
the
asn-1c
encoding
of
a
public
subject:
public
key
and
what
that
looks
like
in
qr,
and
this
is
all
defined
in
the
dpp
spec.
G
G
That's
called
a
dpp
configurator,
so
typically
this
could
be
mobile,
app
or,
alternatively,
the
configurator
could
be
embedded
into
the
wi-fi
access
point
and
proof
of
knowledge
is
carried
out
via
divi
helmet
exchange
and
between
the
configurator
and
the
supplicant,
and
it
uses
the
booster
key
of
the
supplicant
and
the
configurator
generates
an
ephemeral
development
key
as
well,
and
the
supplicant
proves
it
knows.
The
private
key
of
the
booster
key
pair
and
the
configurator
proves
that
it
knows
the
public
key
to
boost
your
key
pair
and
then
a
secure
step.
G
A
secure
channel
is
established
and
step.
Three
network
information
is
securely
exchanged
and
then
step
four.
The
supplement
attaches
to
the
network.
So
in
summary,
the
the
configurator
and
the
supplicant
establish
a
secure
handshake
where
the
configurator
proves
to
the
supplicants
that
it
knows,
the
supplicants
puts
their
public
key.
The
supplicant
proves
it
knows
a
private
key
once
that
secure
channel
is
established,
the
configurator
imprints,
the
supplement
with
network
information
and
network
credentials,
and
then
the
subsequent
will
attach
to
the
network.
G
The
raw
public
key
and
the
server
generates
it's
a
thermal
key
pair
and
then
the
two
sides
can
complete
that
second
divi
helmet
exchange,
so
both
different
helmet
calculations
are
injected
into
the
key
schedule,
using
the
mechanisms
outlined
in
the
draft
of
reference
there
and
there's
also
the
alternative
draft,
which
is
which
is
referenced
in
in
our
document.
The
hybrid
design
draft,
so
there's
multiple
ways
of
figuring
out
how
to
inject
that
second
piece
of
information
into
the
key
schedule.
G
So
these
these
are
extracts
from
the
draft.
It
shows
you
the
shape
of
the
bootstrap
key
extension
and
that
extension
can
be
sent
to
either
a
client
law
or
server
law
in
a
client
at
all.
It's
just
a
hashed
reference,
a
hashed
reference
to
the
public
keys
that
allows
the
server
to
look
up
the
public
key.
Unlike
a
standard
key
exchange,
you're
not
selling
the
full
raw
public
key
you're,
sending
it
a
hash
representation
which
allows
the
server
to
look
up
the
public
key
and
in
the
server
law.
G
The
server
is
exchanging
their
ephemeral,
difficult
key,
their
second
department.
If
you
haven't
key
alongside
the
standard
key
exchange,
so
you
can
see
that
illustrating
the
call
from
the
bottom
left.
The
client
sends
the
bootstrap
key
and
it's
client
load.
The
server
sends
back
it's
a
corresponding
bootstrap
ephemeral
key
in
its
server
law.
G
So
what
this
means
for
an
operator
perspective
is
everyone
is
happy.
If
you
have
a
device
that
you're
trying
to
onboard
the
device
has
a
an
associated
bootstrap
key,
which
could
be
embedded
in
the
firmware
dynamically
generated
on
a
label
whatever,
and
that
qr
code
is
scanned
into
the
network
and
regardless
of
whether
you're
connecting
device
via
wired,
using
dpp
or
via
sorry,
by
wireless
using
dpp
rfi
wired.
G
Tls
proof
of
concept
has
exactly
the
same
security
stance
as
the
wi-fi
alliance
tpp
with
respect
to
those
bootstrap
keys.
So
for
dpp,
if
you
know
the
bootstrap
public
key,
you
can
claim
the
device
and
exactly
the
same
is
applicable
here
for
tds
proof
of
knowledge
when
you're
doing
unwired.
If
you
know
the
booster
public
key,
then
the
network
can
claim
the
device
so
we're
not
making
any
changes
to
the
overall
security
stance
there.
G
We
do
have
working
code,
we
will
just
work
in
tls.code.
That's
been
up
on
it's
up
on
github
for
quite
a
while.
Now,
for
since,
before
the
last
itf,
it's
built
using
it's
built
on
top
of
the
standard
goal
line,
mid
stack
that
would
that
the
guys
in
the
tls
working
group
have
done
loads
of
proof
concepts
on
top
of,
and
this
last
slide
discussion
and
next
steps.
G
There's
three
general
work
areas
here:
one
is
defining
the
tls
extensions
to
transport
that
booster
key
and
that's
a
pretty
small
trivial
piece
of
work.
Second,
is
the
enhancements
to
the
key
schedule
to
inject
that?
Second,
if
we
have
an
exchange
into
the
key
schedule
and
we're
hoping
to
piggyback
on
one
of
the
existing
drafts,
either
holland,
one
or
the
hybrid,
the
hybrid
key
exchange
one,
there
will
be
some
per
tip
extensions,
defined
and
required
to
leverage
how
to
define
how
to
leverage
that
utilis
proof
of
knowledge
handshake.
G
That
work
is
still
that
work
still
needs
to
be
completed
and
with
some
general
discussion,
questions
here
well,
obviously,
the
first
one
is
to
run
a
general
interest
in
this
and-
and
the
other
question
is:
where
does
this
work
fit?
And
we
could
cover
this
in
one
document
that
it
currently
is?
Or
do
we
split
it?
G
G
Did
we
start
an
emu
move
to
tls
says:
do
we
have
to
split
some
of
the
work
between
emu
and
tls
and
those
are
the
kind
of
things
we'd
like
to
discuss
and
that
is
it
that's
the
end
of
the
presentations,
it's
pretty
short
and
but
we
feel
it's
a
it's.
A
pretty
elegant
solution
for
security,
bootstrapping,
a
device
onto
a
wired
or
wi-fi
network
and
the
the
there
is
working
code.
G
B
I
think
right
now.
I
don't
think
if
I
remember
correctly,
hoiland
isn't
a
working
group
item.
Yet
that's
correct,
that's
correct,
it's
not
sure
so
yeah
and
I
think
there
is
interest
in
it,
but
the
word
group's
kind
of
been
working
through
some
other
items
and
that
hasn't
come
up
again
yet
so
that's
probably
something
we
want
to
I'll,
probably
talk
with
jonathan
and
other
folks
and
see
what
their
plan
is
with
that
draft
and
as
far
as
the
extension,
I
think
you
know.
B
G
H
Hi
good
good
morning,
good
afternoon,
good
evening,
so
clearly
there's
a
there's,
a
pretty
clear
use
case
for
eat,
but
I
wouldn't
exclude
the
idea
that
it
might
be
used
elsewhere
at
a
higher
layer
right,
but
that
doesn't
mean
the
work
couldn't
be
done
in
emu.
It
just
means
that
we
shouldn't
write
the
code.
We
shouldn't
write
any
extensions
that
you
know
that
would
exclude
the
use
of
email.
G
J
But
I
guess
my
question
or
comment.
I
had
started
to
say
in
the
jabber
room,
but
it
seems
like
we're
using
a
standard
private
key
pair
for
the
bootstrapping
keys
here,
and
I
was
wondering
if
there
was
a
way
that
we
could
be
able
to
use
like
threshold
crypto
instead
to
fulfill
the
same
goals
without
sort
of
relying
on
this
weird
mechanism
where
you
are
not
treating
the
public
key
as
or
so
you're
you're
treating
the
public
key
as
something
that
is
not
widely
distributed.
Like
it's
supposed
to
be
secret
as
well.
G
So
if
I
can
answer
well,
I
I
just
see
daniel's
in
the
queue
as
well,
but
one
answer
I
have
is:
we
haven't
considered
threshold
crisp
crypto,
but
we
had
been
looking
at
complete
reuse
of
the
dpp
bootstrap
key.
So
we
want
on
the
bootstrap
key
and
dpp
is,
is
a
currently
defined
and
published
wi-fi
line
standard,
and
we
want
to
reuse
that
exactly,
as
is
as
the
bootstrap
key
and
now
I
don't
know
whether
dpp
is
uninterested
moving
to
some
kind
of
threshold
of
crypto.
I'll
refer
to
that
on
that.
F
J
C
B
G
Paul
stood
into
the
chat
as
well,
the
other
draft
that
we've
referenced
as
the
alternative
schedule
import
and
it's
the
the
hybrid
design,
one
that
has
been
a
draft
adopted
by
tls.
So
we
looked
at
both
we
implemented.
What
looked
like
the
simplest
and
most
concrete
thing
at
the
time
six
months
ago,
which
was
the
highland
draft.
B
Okay,
I
think
you
know
it
would
be
good
to.
I
think
it
would
help
your
case
in
tls.
I
don't
know
how
much
interest
there
will
be
in
in
there
for
this
particular
thing.
We
can
certainly
check
that
out
on
its
own,
but
if
this
is
something
that's
of
interest
within,
you
know
the
emu
space.
I
think
that
kind
of
helps
the
case
of
of
working
on
an
extension
either
in
in
tls
or
or
in
this
working.
F
C
G
G
E
K
E
G
C
B
B
F
B
B
Yeah
sure,
so
I
think
that
you
know,
I
think
the
question,
though,
is
is
we
we
have
noob
is.
Is
this?
Is
this
a
mechanism
that
people
think
would
you
know
would
be
a
good
topic
for
emo
to
work
on?
This
isn't
like
this
is
just
to
get
an
idea
of
what
people
feel
at
this
point
in
the
room,
or
did
I
misunderstand
your
quest
pure
comment.
C
C
B
B
B
Okay,
so
so
there
is
some
interest,
so
I
think
that
that's
promising
I
mean,
I
think
it's
good,
that
it's,
you
know
kind
of
bridging
the
gap
between
what
dpp
does
and
what
can
be
done
on
wired.
So
it
definitely
seems
to
me
like
there
could
be
place
for
it,
so
we
we
need
to
have
more
discussion
on
the
list,
but
I
think
we
need
to
move
on
to
the
next
presentation
is
my
bling
on.
N
M
M
M
M
Certificates
are
really
now
used
in
fps,
but
still
some
problems
with
traditional
certificates,
such
as
management,
cost
lodge
certificate
chains
and
intermediate
certificate
is
not
so
friendly
to
the
constrained
environment
devices
such
as
iot
devices,
especially
for
weak
computing
power
devices.
So
I
think
there
are
two
solutions.
One
is
to
simplify
the
certificate
and
intermediate
validation
process.
Another
is
use
a
new
merge
search
for
the
authentication.
M
Of
course
we
choose
the
letter.
What's
your
public
key
in
the
owens
presentation,
most
of
us
have
no
republican.
That
means
there
is
no,
if
no
information
arden
than
the
public
key
for
cryptography,
sentient
sacred
kings
are
more
lightweight,
but
the
disadvantage
is
also
very
upwell,
such
as
the
dating
operation.
So
why
not?
Try
to
use
asmt,
cryptography
public
and
the
private
keys
are
involved.
M
M
In
the
rfc,
rfc6507
specified
an
identity-based
signature,
algorithms
using
elaptic
curve,
cryptograph,
the
mathematical
calculation
method
of
signature
and
the
verification
is
provided,
and
we
also
notice
that
fc
sam250
specified
using
raw
public
key
with
two
extensions,
makes
the
raw
public
key
and
variable
in
ts
and
dtls
next
slide.
Things.
M
Literature,
yes
think
so
the
however
draft
we
can
complete,
we
can
divide
into
three
parts.
Part
one
is
about
the
structure
of
the
raw
power
breaking
extension
and
part.
Two
is
about
ifts,
1.2
extends
republican
in
authentication
procedure
and
part
3
is
about
if
just
1.23
authentication
procedure
next
slide
thanks.
M
M
Server
certificate
type
here
means
the
types
of
server
certificate.
The
kind
is
able
to
process
this
client
certificate
type
means
the
type
of
certificate
the
kind
can
provide
to
the
server
after
receiving
the
current
loan.
The
server
will
respond
with,
say
hello,
and
these
two
new
extensions
also
exist
here.
M
From
the
hello
side,
the
current
certificate
type
indicates
the
selected
type
of
client
certificate
type
of
client
certificate
and
the
extension
of
server
certificate
type
here
indicates
the
type
of
certificate
certificate
in
their
following
certificate
load.
What's
more
important
is
the
extension
of
certificate.
M
M
The
third
one
is
the
hash
value
after
us
algorithms,
fabric
parameters
after
receiving
their
message
from
the
server
the
quite
well
verified
and
the
signature
message
same
id
and
the
public
parameters
will
be
their
input
and
then
this
the
peer
will
verify
their
signature.
If
success
declined
will
also
send
their
own
certificate
with
the
same
form
of
the
server
after
several
verified
the
client
certificate,
it
means
their
virtual
authentication
complete
and
the
whole
king
develop.
Derivation
is
also
complete.
M
M
M
What's
more,
the
certificate
here
will
carry
the
I
object:
identity
for
ecsi,
that's
the
wrong
mass
value
here,
and
the
hash
value
of
the
public
parameters
and
also
that's
their
id.
That's
their
public
key
and
also
their
certificate
request
will
carry
eccs,
I
sure
205
6
they.
That
means
they
want.
Their
current
site
will
also
use
their
easies,
as
I
sure
two
hundred
fifteen
six.
M
M
B
M
M
E
M
M
C
M
M
M
M
B
Yeah,
so
we
had
a
busy
time
with
tea
paradis.
Since
the
last
meeting,
I
think
we
we
had
a
total
of
10
errata,
published
or
or
submitted
against
teep.
I
think
on
the
list.
We've
resolved
six
of
those,
and
I
think
four
of
them
are
really
close,
and
I
wanted
to
kind
of
go
through
them
today
with
as
many
people
as
we
could
here.
B
I
did
get
some
comments
on
the
list
from
oleg,
so
I
know
he's
looked
at
them,
but
I
want
to
make
sure
that
that
people
have
looked
at
them
and
if
there
are
any
comments
today,
then
we
can
chat
about
it.
So,
let's
see
the
first
one
we
have
is
has
to
do
with
the
authority
id,
which
is
a
tlv,
an
outer
tlv
and
currently
the
draft
or
sorry,
the
the
the
rfc
says
that
this
should
be
mandatory
and
the
the
problem.
B
B
B
B
B
So
my
thinking
here
is
that
this
is
something
that
we
would
hold
for
a
document
update,
because
there's
really
too
many
places
to
update
it,
just
doing
it
in
an
errata,
and
so
the
errata
would
be
hold
for
a
document
update,
and
we
can
place
a
note
explaining
the
reasons
why
we
want
to
make
that
change.
But
the
change
would
be
made
when
we
update
the
document.
B
B
C
So
what
I'm
saying
is
that
for
me
and
hopefully
for
most
other
people,
I
could
be
wrong
if
method
generally
means
an
eep
authentication
method,
which
was,
I
guess,
the
intended
meaning.
When
deep
was
written
and
I
haven't
now
looked
at
the
deep
rfc.
Maybe
I
should
check
it
again,
but
if
there
are
some
instances
of
identity
method,
it
might
make
sense
to
like
change
those
to
an
identity
message
or.
B
B
A
B
All
right,
so
I
I
mean
we
can
take
a
look
and
and
take
a
look
at
the
at
the
rfc
and
see
if
you,
if
you
think
there
is,
if
there's
a
simple
change
to
make
that
isn't
like
you
know
in
15
different
sections,
then
that
that
might
be
worthwhile
doing.
But
this
is
borderline
almost
an
editorial
change.
It
does
have
some
technical
meaning
in
some
places.
C
B
And
whether
you
send
an
interme
and
when
you
derive
keys
and
when
you
do
interme
intermediate
results
and
crypto
binding
and
so
the
real
question
was
it
didn't
really
specify
whether
you
did
crypto
binding
after
a
basic
password
exchange.
It
didn't
make
that
clear,
and
so
we've
made
some
modifications
here
to
kind
of
make
it
clearer
what
you
do,
and
so
that
also
we
defined
made
sure
the
procedure
for
when
you
don't
have
a
key
generated,
such
as
in
a
password
method.
B
B
B
C
C
O
C
O
B
B
B
Yeah,
that's
where
we
are
so.
If,
if
you
could
take
a
look
at
the,
I
think
that
that
could
be
a
fine
idea
if
we
just
if
it's
just
an
addition
in
one
of
the
current
errata,
which
I
think
it
could
fit
into
that
would
would
be
good
because
I
I
think
the
intention
is
that
if
a
method
is
generates
an
msk
that
it
should
be
used.
B
B
B
B
B
B
B
B
B
Well,
so
are
there
any
other
comments
on
these
errata
or
any
of
the
other
errata
that
we
didn't
discuss?
Yet?
I
think
we
have
still
have
one
open
issue
which
oleg
brought
up,
which
we
can,
I
think,
that'll,
be
pretty
quick
to
resolve,
but
I'd
like
to
try
to
wrap
these
up
and
send
them
to
roman,
so
he
can
figure
out.
C
L
Yep
I
apologize.
I
sent
an
email
to
the
list
just
right
before
this
meeting,
so
I
doubt
anybody
has
had
time
to
review
it
and
think
about
it,
but
errata
5768,
the
chrome
code
is
too.
It
involves.
The
hmac
and
hmacs
have
different
lengths
depending
on
the
algorithm
used,
and
so
it
relates
to
changing
the
length
in
the
crypto
binding
tlv
to
be
variable
based
on
the
type
of
hmac
used,
which
sounds
good
to
me.
But
I
do
have
some
compatibility
concerns
because
the
existing
document
says
the
crypto
binding
tlv.
L
B
Tlv
yeah,
so
then,
if,
if
existing,
I
think,
if
we're
going
to
increase
the
version
of
the
crypto
binding
tlv,
that's
like
a
document
update
and
what
we
could
do
in
the
errata
is
is
clarify
what
the
existing
behavior
is.
I
mean
if,
if
existing
implementations
are
doing,
you
know
shot
or
shot
256
and
then
truncating
it
to
20,
bytes
and
and
those
are
existing
implementations.
L
H
H
Thank
you
for
all
of
your
work
on
this,
and
it
was
a
lot
of
work
and
it
took
a
lot
of
effort
to
just
get
all
get
slogged
through
all
these
and
a
thanks
to
yoni.
Even
though
he's
not
here
first,
I
agree
with
the
last
point
that
that
one
should
be
hold
for
update,
but
the
reason
I
got
on
the
microphone
was
to
say
and
now
that
we're
getting
through
these,
I
want
to
unstick
the
the
deep
update
I
didn't
want.
I
couldn't
do.
H
H
I
think
owen
is
on
it
and
a
couple
of
others
we'll
probably
want
to
incorporate
a
few
other
things
to
make
sure,
for
instance,
that
the
the
poke
work
is
is
incorporated
depending
on
you
know
or
or
that
we
can
easily
update
on
top
of
the
update
as
it
were,
with
with
it
with
a
separate
drop
for
poke,
and
we
can
make
some
decisions
about
that
depending
on
timing.
So
again,
thanks
for
all
the
work
it
was,
it
was
a
lot
of
work
and
I
personally
appreciate
it.
B
Great
yeah
it'll
be
it'll,
be
good
to
kind
of
get
our
revision
going.
I
think,
especially
now
that
we
have
implementations.
I
think
the
this
experience
with
teep
really
solidifies.
I
think
the
areas
where
we
had
most
of
the
problems
are
areas
which
were
not
did
not
receive
as
much
implementation
at
the
time,
and
so
implementation
is
is
key
in
when
we're
working
through
these
issues.
H
C
B
A
A
I
I
don't
really
need
anything
more
other
than
I
may
have
kind
of
the
occasional
questions
when
I
personally
drop
it
into
into
the
interface,
but
it
looks
like
you
have
all
the
necessary
things
and
you
everyone,
we've
walked
it
through
the
working
group
to
make
sure
that
we're
all
on
the
same
page.
So
this
is
phenomenal
and
when
you
say
you're
done,
I
mean
I'll
I'll
start
dropping
it
into
the
errata
interface.
Thank
you
really
again.
This
is
awesome.
B
C
C
So
yeah
hi
this
is
a
short
update
on
eat.
Noob,
I
think
by
now
people
are
familiar
with
what
this
method
does
so
next
slide.
Please
yeah
generic
authentication
framework
and
there's
no
methods
that
do
ob,
authentication
so
yeah.
This
is
a
new
method
for
doing
that.
Next
slide,
it
basically
does
user.
C
C
We
adopted
it
as
a
working
group
item
in
earlier
this
year
and,
like
the
draft
already
was
stable
when
it
was
adopted
and
now
like
we
got
like
reviews
from
harness
from
the
iot
directorate
from
security
directorate
and
basically
the
working
group
portions
have
been
updating
the
draft
based
on
on
these
reviews.
So
now
we
are
at
working
group
version
two.
So
that's
the
stage
we
are
currently
at
next
slide.
C
At
least
we,
the
authors
believe
that
it's
ready,
there's
three
implementations,
two
two
of
them
in
wps
applicant
and
host
apd,
and
one
in
contiki
there's
formal
models
in
mcrl2,
which
is
basically
for
checking
the
state
machines
and
dos
resistance
and
pro
verify
to
verify
the
security
goals.
So
the
difference
between
the
two
implementations
in
supplicant
host
apd,
the
first
one
is
more
feature
rich.
C
So
it
does
all
sorts
of
things
like
nfc
from
peer
to
server
and
server
to
peer,
whereas
the
the
third
implementation
on
this
bullet
list
is,
I
would
say,
more
streamlined
and
stable
and
less
feature-rich.
So
it's,
I
would
say,
like
less
bugs
and
less
features
and
more
stable
implementation,
which
was
completely
rewritten
earlier
this
year
after
the
draft
was
working
group
adopted.
C
C
So
what
was
happening
that
the
the
reconnect
exchange
was
not
triggered
in
the
state
machine
at
the
right
time,
and
this
caused
the
reconnect
exchange
to
fail
and
miguel
from
analog
devices
then
actually
send
the
pull
requests
to
the
implementation.
There's
several
others,
I'm
not
sure
if
they
want
to
be
named
here
and
listed
here.
C
C
Maybe
it's
fine
to
just
stick
with
json
and
let
this
go
through
and
of
course,
eep
new
has
secure
version
negotiation,
so
you
can
perhaps
think
of
a
future
version
of
heap.
Nowhere
which
supports
seaboard,
although
I
think
we
will
have
a
presentation
after
this
on
epaddock,
which
perhaps
is
more
suitable
for
the
extremely
constrained
devices
where
you
know,
seabor
is
more
likely
to
be
a
necessity
rather
than
the
case
of
eat
noob.
C
So
for
now,
given
that
you
know
we
have
these
deployments
coming
up,
I'm
a
bit
concerned
that
moving
this
to
seabor
is
not
worth
the
benefits,
and
I
mean
if
there
is
strong
requests
in
the
future.
This
can
be
done,
but
at
this
stage
it
feels
like
the
really
constrained
devices
may
prefer
then
to
go
with
the
ad
doc.
For
example,
next
slide.
C
C
We
got
inr,
okay,
with
the
current
request,
whether
it's
for
the
method
type
or
the
special
domain
name,
and
I
would
like
to
thank
wes
hardiker
from
the
iab,
who
kind
of
did
the
hand
holding
and
explained
the
process
and
it's
nice
that
I
and
I
can
do
this
early
reviews
to
confirm
and
weed
out
any
issues
in
the
inr
requests
section.
So
the
authors
believe
it's
ready
for
our
last
call.
C
B
C
N
Can
you
hear
me?
Yes,
we
can
go
ahead.
Wait.
Thank
you
well,
thank
you
for
having
me
today.
I
am
edward
ingress
and
I'm
going
to
present
this
draft
published
with
dan,
garcia
and
rafa
marin.
The
draft
includes
the
initial
idea
of
the
new
method
for
it
based
on
adult
country.
Authentication
protocol
exercise
live
please.
N
Our
goal
is
to
design
an
alternative
solution
for
constrained
devices
using
nedoc
edoc
is
a
protocol
that
is
currently
under
development
at
the
lake
working
group
and
in
this
working
group
they
intend
to
produce
a
lightweight
authenticate,
the
key
exchange
for
oscar
usage
and
they
use
the
silver
protocol
and
recommend
the
use
of
co-op
to
transport
messages.
They
also
want
to
provide
entering
protections.
N
N
N
N
N
K
K
C
N
N
Yep
thanks,
I
guess
thank
you
so
next
slide.
Okay,
thank
you,
so
edok
allows
to
define
which
protocol
is
responsible
for
ensuring
the
correlation
of
messages
so
either
itself
or
the
protocol
or
the
transport
protocol.
Sorry,
in
this
case,
the
if
protocol
is
based
on
the
locasted
procedure
and
guarantees.
The
ordering
of
messages,
therefore
edoc,
doesn't
need
to
use
its
internal
mechanism
for
correlating
messages.
That
means
that
we
set
the
variable
core
to
the
fixed
value.
3
next
slide.
N
N
My
intention
in
this
presentation
is
to
actually
present
the
idea
to
the
community
to
get
your
feedback,
and
our
next
steps
are
to
add.
The
feedback
received,
continue,
adding
the
protocol
details
and
work
on
making
the
design
compatible
with
this
draft
based
on
app
for
radios
next
slide.
Please,
and
to
end
this
presentation,
I
will
be
pleased
to
hear
from
the
participants
whether
they
think
this
draft
makes
sense
as
a
working
group
item
or
not,
and
please
be
welcome
for
any
other
comments.
Thank.
C
C
C
C
K
N
N
C
Yep,
I
guess
joe,
the
next
step
is
to
continue
the
discussion
on
this
draft
on
emu
and
lake
whenever
needed.
If
there
is
some
requirements
that
epad
dock
requires
from
from
a
dog
and
the
lake
working
group,
then
of
course
it
should
not
wait
for
a
dog
to
finish,
but
perhaps
we
can
revisit
this
next
next
idea.