►
From YouTube: IETF113-EMU-20220322-1200
Description
EMU meeting session at IETF113
2022/03/22 1200
https://datatracker.ietf.org/meeting/113/proceedings/
A
All
right,
I
think,
we'll
get
started.
I
don't
know
how
many
people
are
going
to
be
in
here
and
versus
online,
but
this
is
emu
at
ietf
113
here
in
vienna
and
online
next
slide.
Might.
A
You
all
should
be
familiar
with
the
note
well
kind
of
a
code
of
conduct
for
the
ietf
talks
a
little
bit
about
ipr
and
keeping
things
professional
here
in
the
meeting
with
our
discussions
and
thanks
ian
for
offering
to
take
notes
and
if
somebody
else
you
can
easily
get
to
the
notes
through
the
ether
pad
link
on
the
or
the
code,
emd
link
on
the
agenda
and
if
you
can
take
notes
while
jan
is
presenting,
that
would
be
wonderful.
Thank
you.
Next
slide.
A
Okay,
so
there
are
around
the
room,
little
qr
codes
that
you
should
scan
so
that
that's
the
method
for
signing
in
with
your
blue
sheets.
So
please
scan
the
qr
code
so
that
your
attendance
will
be
recorded.
That's
something
you
agreed
to
do
when
you
signed
in
and
for
people
who
are
online.
That's
already
taken
care
of.
A
All
right,
so,
let's
go
to
the
next
slide,
just
a
quick
overview
of
our
agenda,
which
is
packed.
Today
we
have
a
couple
of
working
group
draft
items
so
we'll
have
yari
talk
first
about
aka
pfs,
then
alan
we'll
talk
about
the
eep
types
and
then
we
have
some
other
drafts
that
we
will
go
into
some
of
them.
A
We're
gonna
see
if
there's
some
desire
to
kind
of
take
them
on
as
working
group
items
in
in
this
meeting,
and
if
we
don't
get
enough
information
from
this
meeting,
we'll
have
to
take
that
to
the
list.
The
adoption
call
would
be
taken
to
the
like
list
anyway.
A
Does
anybody
have
anything
to
add
to
this
agenda?
We
don't
really
have
time
to
add
anything,
but
all
right
next
slide.
Please
up
all
right.
Let's
go
to
yari
slides.
B
All
right,
hi
guys,
my
name
is
yadi
arco
and,
together
with
a
couple
of
my
colleagues
and
many
contributors
from
the
working
group,
we've
been
doing
this
forward
secrecy
or
perfect
forward
secrecy
draft
an
extension
of
eap,
aka
next
slide,
and
what
is
the
status
of
that?
It's
been
sort
of
hanging
around.
I
guess
partially,
at
least
due
to
lack
of
cycles
on
the
author's
part,
my
part
in
particular,
but
also
some
final
details.
B
We
were
sort
of
trying
to
nail
down
not
much
but
a
little
bit,
we'll
talk
about
that
in
a
bit
and
waiting
for
you
know
clear
opportunity
to
put
this
into
real
world
use,
but
I
at
least
I'm
a
little
tired
of
waiting.
So
I
think
it's
better
that
we
make
this
an
rfc
and
nail
those
final
details
and,
and
then
it's
ready
to
be
used,
and
I
think
it's
important.
Of
course,
the
forward
secrecy
property
is
important
for
security
next
slide,
so
we
submitted
the
new
version.
B
06
has
a
couple
of
changes
not
much
at
least
not
substantially
much.
We
updated
some
of
the
references
because
they've
been
made
rfcs
recently.
B
Okay,
no
biggie,
there's
also
a
discussion
in
itf
in
the
sarc
group
about
the
use
of
pfs
terminology,
and
they
came
to
the
conclusion
that
one
should
use
forward
secrecy
instead
and
so
we're
trying
to
comply
with
the
conclusion
of
that
discussion.
There's
a
link
on
the
slide
to
mail
that
john
sent
to
the
list.
I
think
so
we
made
that
change
and
so
that
that
sort
of
editorially
fairly
big
change,
because
it
shows
up
on
many
places
in
the
document
we
change
the
name
next
slide.
B
B
Occasionally
at
least,
and
my
interpretation
of
the
discussion
was
that
it
did
not
result
in
in
a
conclusion
that
I
I
could
easily
implement
in
the
draft.
So
I
asked
the
working
to
to
take
a
look
at
this,
in
particular
the
people
who
were
participating
this
john
and
renee
and
mohit
you
as
well,
and
maybe
others.
B
So
the
question
is
about
the
encoding
of
the
public
value
and
how
long
it
is
and
so
on
and
you
can.
You
can
look
up
the
the
discussion
on
the
mailing
list
archive,
but
from
my
perspective
I
need
some
some
input
from
the
working
group
or
from
from
the
guys
I'm
not
the
expert
on
this
encoding,
so
I'm
kind
of
looking
to
others.
B
Maybe
my
person's
you
can
say
something,
but
basically,
on
the
right
side
of
the
slide,
you
can
see
the
the
the
actual
text
that
we
have
right
now,
let's
talk
about
two
curves
and
how
they
are
encoded
and
then
there's
some
discussion
between
john
and
renee,
for
instance,
on
whether
it
should
be
32
or
33
and
what
the
implications
are
so
that
that
that's
the
open
issue.
I
don't
know
if
people
have.
A
Thoughts
now
or
so
I
think
john,
is
in
the
queue
and
in
in
theory
you
should
join
the
mike
q
through
your
mobile
app,
but
so
john
go
ahead
and
then.
C
Yeah,
so
I
I'm
fine
with
this
33.
I
mostly
had
comments
about
the
reasons
and
some
of
the
motivations
behind
the
change
and
some
of
the
statements
regarding
32
byte
values.
Otherwise
I
find
this
33
byte
encoding
perfectly
fine.
I
don't
have
anything
against
that,
so
I
think
we
can
more
or
less
close
this
issue.
If
there's
anything
to
do,
I
think
it
then
it's
small
non-technical
clarifications
in
the
draft
or
something
3d.
People
already
use
this
33
byte
code
compression
in
in
suki
for
example.
C
So
I
don't
have
any
I'm
I'm
fine
with
the
current
33
byte
yeah.
B
C
D
Dan
dan
harkins,
so
the
only
reason
you'd
need
the
extra
byte
is,
if
you
care
about
the
sign
of
the
point.
But
if
you're,
if
your
shared
secret
is
just
the
x
coordinate
of
the
the
divi
helmet
shared
secret
point
and
you
throw
away
the
y
coordinate,
they
don't
care
about
the
sign
anyway.
So
you
don't
need
you
don't
need
the
extra
bite
you
don't
it's.
It's
not
helpful.
B
There
was
also
discussion
by
renee
about,
like
you,
were
seeing
the
same
encoding
exactly
as
others
and
what
the
libraries
do
and
so
forth.
So
I
don't
know
if
that
played
the
role
in
that
discussion,
but.
D
Yeah
well,
it
was
encoded
as
33
because
they
wanted
to
compress
it,
but
there's
some
use
cases
required
both
sides
to
have
the
exact
same
sign
representation
so
that
that's
what
the
byte
is
for.
So
you
can,
whether
it's
you
know
plus
y
or
minus
y,
but
if
you're
throwing
away
y
anyway,
then
you
don't
really
care
what
the
sign
is,
and
I
think
you're
throwing
away.
Why
in
in
this
in
pfs
draft
right.
C
I
agree
with
everything
dan
says
this.
This
single
bite
is
not
really
useful,
but
it
doesn't
really
matter
so
much
either.
So
I
I
personally
don't
have
a
strong
opinion.
I
think
com
clients,
most
libraries,
doesn't
support
this
33
byte
either.
So
to
get
compliance
you
need
64,
byte
encoding,
mostly
but
but
yeah,
but
it's
a
single
bike
we're
talking
about
so
it
might
not
be
such
a
big
issue.
I
can
live
with
both
personally.
A
E
E
In
that
case,
we
should
just
follow
whatever
3gbps
is
using
just
just
because
it
will
be
like
lesser
path
of
resistance
for
them
to
hopefully
adopt
once
this
becomes
an
rfc,
and
I
don't
know
if
aka
bfs
is
going
to
be
used
in
super
super
constrained.
B
Okay,
so
if
I'm
trying
to
summarize
the
discussion-
just
just
my
opinion,
of
course,
but
it
sounds
to
be
like
nobody
is
objecting
to
what
we
actually
have
now.
B
It
also
sounds
like
it's
useful,
maybe
for
me
and
john
to
go
through
some
of
the
stuff
offline,
particularly
like
the
references
and
and
that
there's
no,
no
other
other
language
anywhere
in
the
draft.
That
would
actually
speak
about
some
of
these
things
that
we
were
arguing
a
little
bit,
but
but
substance
seems
to
be
acceptable
unless
somebody
screams
now.
A
Yeah,
I
think
if,
if
you
guys
could
go
on
and
kind
of
make
a
final
decision
and
and
update
the
draft
if
necessary,
and
then
you
know,
let
us
know,
and
then
we
can
start
working
group
last
call.
I
think.
F
Hi,
I
just
had
a
question
about
like
using
33
bytes.
I
guess
this
question
is
like
with
the
libraries
I
guess
they
introduced
some
ambiguity
because
you
don't
know
they
might
expect
they
might
libraries
might
want
to
know
which
white
coordinator
they
should
take,
and
so
that
could
you
know
that
could
be
an
issue.
B
So
I
think
the
spec
will
say
exactly
what
to
do
and
whether
that
matches
the
library
that
you
have
easily
available
or
not
is
another
question.
I
think
we're
discussing
that
like
what
is
the
right
choice
here
in
terms
of
making
that
that
thing
easy
with
with
the
implementations?
B
Well
that
that's
part
of
it
at
least
but
but
the
spec
will
be
clear
that
you
have
to
do
that.
Like
you
know
this
many
bytes
and
go
read
here
what
you
know,
what
the
what
the
format
is
and-
and
I
don't
think
that's
this
ambiguity
after
that-
this
only
ambiguity
here,
deciding
that
what
should
the
spec
say
but
after
after
it
says
something
I
think
it
should
be
should
be
clear
and
if
it's
not,
then,
then
we
have
a
problem,
but
I
don't
think
we
do.
B
G
Jonathan
to
build
off
what
nick
said,
so
it's
not
an
ambiguity.
It's
just
that
when
most
cryptographic,
libraries
as
john
pointed
out,
requires
64
bytes,
then
you
would
have
to
with
a
32
byte
representation.
D
You
have
to
do
those
computations
with
33
bytes
anyway,
I
mean
the
only
thing
that
extra
byte
tells
you
is,
which
y
to
use
you
still
have
to
to
do
the
equation
of
the
curve
to
get
y
squared.
You
take
the
square
root,
and
now
you
just
decide
whether
it's
plus
y
or
minus
y,
based
upon
the
the
third
byte.
So
you
have
to
do
the
work
anyway,
whether
you
have
the
33rd
bite
or
not,.
A
Okay,
so
I
I
think
we
still
have
the
same
direction
for
for
the
author
and
authors
to
kind
of
go,
look
at
what's
available
in
terms
of
libraries
and
other
specs
and
come
up
with
a
proposal
that
we
can
then
run
by
the
group
all
right
thanks
all
right.
Next,
we
have
alan
with
tlse
types.
H
Okay,
my
linkedin
looks
to
be
linked.
I
think
there's
only
one
slide
here.
So
if
we
go
to
the
next
one
mo
heat,
multiples,
client
server,
implementations,
it's
allegedly
good
to
go.
One
issue
raised
was
sort
of
a
throwaway
comment
in
the
ttls
rsc
that
it
should
be
okay
to
do
client
authentication
using
only
the
client,
skirt,
cert
and
just
a
skip
phase.
Two,
I
don't
know
anyone
that's
implemented
that
it
seems
a
little
weird.
H
If
you
want
to
use
client,
cert
authentication,
you
should
just
use
tls
and
the
suggestion
was
to
forbid
that
in
tls
1-3
for
both
ttls
and
peep.
That
doesn't
seem
controversial.
H
So
I
think
it
should
be
okay,
it's
already
in
the
the
last
issue.
Last
version
of
the
draft
I
published
and
no
one
seemed
to
comment
too
much
on
the
list.
The
other
issue
which
showed
up
in
the
last
week
or
two
is
a
client
deciding
to
not
do
session
resumption
for
ttls
the
issue
with
pap
when
you
do
ttls,
plus
pap,
there's
only
one
even
half
round
of
information
being
sent
from
the
supplicant
to
the
server
here's
my
password
and
the
answer
is
deep
success
or
eep
failure.
H
H
The
larger
issue
is
that
if
we
send
a
session
ticket
instead
of
eve,
success
or
failure,
this
implementation
decides
it's
unexpected
and
treats
it
as
reject.
So
I
would
suggest
updating
the
document
to
suggest
that
this
is
not
the
proper
thing
to
do,
and
you
should
continue
doing
tls
whatever.
That
means
until
you
get
the
deep
success
or
eat
failure,
and
this
is
perhaps
a
side
effect
of
not
having
that
protected
success.
H
A
All
right
does
anybody
in
attendance
have
comments
about
that
issue.
Mohit.
E
Maybe
not
so
much
on
on
this
second
day
issue,
I
haven't
had
a
closer
look
at
it,
but
this
allowing
clients
are.
I
think
this
should
be
acceptable.
I'm
just
worried.
E
Are
we
not
aware
of
some
niche
deployment,
and
would
it
make
sense
to
for
us
cheers
to
send
like
a
heads
up
that
this
update
of
let's
say,
ttls
and
peep,
specifically
highlighting
this
rfc
numbers,
5281
saying
that
we
are
basically
going
to
forbid
client
or
that
client
authentication
with
client
certificates
only
in
which
case
you're
better
off
with
using
dls?
And
if
you
have
any
implementation
or
use
cases
where
you
are
doing
that
say
now
or
then
then
don't
complain
later.
I
Tim,
hey
tim,
cabelly,
mac,
os
lets
you
configure
it
via
profile,
whether
it
works
or
not.
I'm
not
sure.
H
From
what
I
can
tell
the
peep
specs
are
silent
on
this
issue,
so
implementations
may
or
may
not
support
this.
I
know
with
with
my
server
implementation.
You
can
configure
this,
it's
pretty
rare.
So
far
as
I
know
for
for
me
I
mean
it's
one
of
these.
Things
of
it
doesn't
really
break
anything
to
allow
this,
but
I
tend
to
be
a
little
conservative
in
the
we
already
have
a
client
certificate
authentication
method.
H
If
you
want
to
use
client
certificates
only
you
should
just
use
that
and
so
forbidding
it
in
the
document
you
know,
given
our
experience
with
various
similar
forbiddings
doesn't
really
necessarily
affect
implementations,
but
perhaps
serves
as
a
warning
that
this
doesn't
really
make
sense.
If
you
want
something
with
a
phase
two
authentication,
then
you
should
be
using
the
phase.
2
authentication,
and
we
really
don't
know
why
or
what
the
benefits
are
use
cases.
H
A
Issue,
if
not,
I
think
we
want
to
try
to
resolve
this
discussion
on
the
list,
and
so
we
can
get
a
new
draft
spun
up
and
move
it
forward.
So
I
don't,
I
think,
we're
we're
pretty
close
on
this
one.
H
Yeah
I'll
get
a
new
draft
out
after
ietf
and
I
think
we
should
be
good
to
go.
A
H
There's
only
one
slide
here
again,
not
a
lot
to
discuss.
I
did
issue
a
new
update
with
some
minor
tweaks
and
all
this
really.
What
this
is
is
this
is
this
is
a
way
not
just
to
configure
eve,
but
it
it's
a
trade-off
in
cost.
H
There
are
possibilities
like
fast
teep
and
some
other
proposals
later
in
this
meeting,
where
you
use
eep,
almost
as
a
general
transport
protocol
to
transport,
all
kinds
of
provisioning
information
and
there's,
provisions
for
queries
and
teep
has
provisions
for
requesting
client
certificates
and
pushing
all
kinds
of
information
back
and
forth,
and
speaking
as
an
ape
implementer
and
someone
deploying
and
supporting
these
things,
it
gets
complicated.
H
It's
certainly
easy
in
some
respects
for
administrators
who
support
this
just
to
click.
A
button
saying
allow
provisioning,
but
it
makes
the
implementations
more
fragile.
H
So
there
is
a
little
bit
more
work
for
site
administrators
to
set
this
up,
but
the
nice
thing
is
once
it's
set
up:
you
really
don't
care
what
else
is
going
on
in
your
network,
it's
independent
of
eep
type,
etc,
etc.
So
we
do
have
buy-in
from
a
bunch
of
people
to
move
forward
with
this
implement
this.
J
Hey
good
afternoon
to
those
in
the
room
good
morning
to
people
who
aren't
in
the
room
and
elsewhere
in
the
us,
alan
thanks
for
this
draft.
I
looked
this
over
a
long
time
ago.
J
There
were
there
were
a
couple
of
issues
that
I'd
seen
back
then,
but
I
just
wanted
to
address
one
point
here:
first,
which
is
my
focus,
is
really,
as
you
guys
know,
on
iot,
where
you
don't
have
user
interfaces,
you
need
standard
interfaces
to
run
things,
and
one
of
the
standard
interfaces
we
need
is
a
way
to
get
a
certificate
so
and
not
just
a
certificate,
but
a
trust
anchor
right.
J
So
the
exact
things
that
you
were
talking
about
in
teep
are
the
exact
things
that
an
iot
device
needs,
and
you
are
suggesting
that
these
be
taken
using
standard
internet
mechanisms.
I'm
presuming
you're
referring
out
to
stuff
like
est
or
acme
or
some
such
can.
You
elaborate
a
little
bit
more
on
where
you
think
you're
going
in
there.
H
Yeah,
the
the
standard
internet
tools
here
really
are
not
sorry.
The
the
intention
here
is
not
so
much
for
iot,
where
you
have
a
device
with
no
ui
no
network
connection.
Looking
to
bootstrap,
that's
a
complicated
thing.
You
definitely
need
something
specific
there
and
yeah.
That
really
does
have
to
look
a
lot
like
eep.
H
Generally
speaking
for
other
devices,
you
know
my
phone,
for
example,
pretty
much
always
has
two
network
connections
wi-fi
and
a
backhaul
on
4g
5g,
whatever
my
laptop,
for
example,
I
can
always
walk
down
to
starbucks
and
get
a
completely
unauthenticated
internet
connection
when
you
do
that,
you
have
dns
https,
acme
est,
whatever
that
will
almost
always
already
be
on
the
device
and
already
have
software
there,
and
so
the
use
case.
H
I
I
really
envision
is
you
know
someone
starting
at
a
new
company
and
you
get
told
yeah
here's
the
standard,
dns
names
for
all
of
our
configuration,
all
the
certificates
etc
are
available
on
https
go
and
do
that.
H
The
the
issue
for
me
is
loading.
All
of
this
into
eep
is
very,
very
complicated
and
when
it
works,
it's
absolutely
fantastic
and
when
it
doesn't
work,
the
user
and
the
administrator
generally
get
messages
like
failed,
and
it
could
be
one
of
16
different
things
which
fails
and
they
have
absolutely
no
idea.
K
Hello
yeah,
so
I
generally
agree
with
where
alan
is
going
with
it.
With
this,
you
know
absent
some
considerations
for
iot
because,
as
was
said
in
the
original
applicability
statement,
eap
is
not
really
good
at
transferring
large
amounts
of
data,
which
would
include
the
configuration
and
that's
why
it's
probably
a
better
approach,
if
you
can
do
it
to
just
get
on
the
network
and
then
download
the
stuff
using
you
know
a
full
tcp
stack
and
the
configuration.
I
don't
know
how
big
it
is
alan,
but
it
can
be
complicated.
H
Yeah
just
to
respond
to
that
I
mean
it's:
it's
certificates,
certificate
chains.
In
the
worst
case,
I've
seen
you
know
64k
of
data,
and
then
people
complain.
K
Right
yeah
in
particular,
yeah.
Those
are
those
are
where
you
get
the
failures,
because
you're
sending
a
lot
of
data.
You
know
you
get
into
all
the
issues
that
we
got
into.
You
know
recently
with
etls
trying
to
shorten
the
certificate
sizes
because
of
those
exact
same
failures,
so
yeah
you're
right,
you're
gonna,
dramatically
improve
the
likelihood
that
configuration
will
succeed.
J
Thanks,
I
mean
my
my
thinking.
Is
we
should
I'm
not?
I
I
understand
ellen's
use
case
we
sort
of
have
two
directions.
We
can
take
direction.
Number
one
is
alan.
You
just
scoped.
The
document
in
terms
of
in
terms
of
these
are
the
use
cases
I'm
trying
to
solve,
and
these
are
the
use
cases
that
may
not
be
applicable
for
this
document.
J
That's
one
approach.
Another
approach
would
be
that
we
see
if
we
can
ponder
the
model
that
we
really
want
that
covers
them
both
and
sometimes
that's
reasonable,
and
sometimes
it's
not
right.
The
the
issues
that
you're
talking
about
in
terms
of
data
transfer
sizes,
there's
probably
timeouts
involved
as
well,
that
that
come
into
play
in
some
of
these
cases
the
link
path
issues
relating
to
you
know.
What's
what's
running
underneath
you
know
there
are
a
myriad
of
problems
that
he
can
run
into,
but
and
it's
nice
to
keep
it
nice
and
thin.
J
On
the
other
hand,
when
it
when
we
push
these
things
into
other
layers,
the
complexity
isn't
just
in
one
place.
It
spreads
into
l3,
for
instance,
where
you
have
trusted
untrusted
mechanisms
that
that
end
up
getting
into
place,
especially
with
the
iot
case.
We
see
this
in
some
of
the
deployments
we
have
and
we'd
like
to
get
away
from
that.
You
know,
because
that
complexity
leads
to
other
problems.
J
So
one
challenge
I
think
we
face
then,
and
it
really
to
me
all
this
pulls
down
to
is
you
know
what
do
you
do
with
teep
and
and
things
like
teep,
you
know:
how
do
we
make?
How
do
we
make
it?
What
is
the
right
approach
to
get
trust
anchors
inserts
and
such
into
a
device
without
having
to
apply
a
whole
lot
of
layer,
3
complexity,
because
that
that
complexity
hurts
too?
It
can
also
be
difficult
for
administrators
to
handle
it
adds
its
own
fragility.
J
So
I'm
not
saying:
let's
not
do
this
draft,
you
know,
don't
don't
get
me
wrong,
I'm
just
saying
that
we
should
you
know
we
should
think
about.
You
know
how
how
we
want
to
tackle
whether
we
want
to
tackle
these
these
problems
together
or
apart,
and
it
may
make
sense
to
tackle
them
apart,
because
you
can,
you
know
at
least
reduce
the
pain
for
some
group
and
you're
right
allen
that
there
are
a
number
of
devices
that
already
have
some
form
of
connectivity
and
maybe
there's
some
relief
here
for
them.
J
You
know
the
the
other
thing
that
we
have
to
think
about
in
terms
of
that
relief.
Is
it
also
may
open
up
attack
surfaces
that
we
want
to
think
about
too?
Specifically,
do
you
you
know:
do
we
really
want?
You
know
the
moment
you
say:
okay,
let's
have
an
est
server
or
something
like
that
to
handle
certificates.
J
You
end
up
thinking
about
how
you
have
to
harden
the
est
server
to
client
requests,
and
if
you
can
put
something
in
between
that
that
that
that
is
already
doing
some
sort
of
policing
that
has
its
own
value.
So
I'm
just
saying
it's.
This
is
a
it's
a
bit
of
a
admire
and
I'm
sure
alan
that
you
know
in
terms
of
you
know
what
you're
doing
you're
living.
J
I
Yeah
tim
paulie,
microsoft,
I'm
alan
super
in
favor
of
this.
It's
frustrating
even
just
to
connect
here.
It
took
me
five
minutes
for
a
ietf.
I
etf.
It
may
make
sense,
in
my
opinion,
to
scope
this
to
user-centric
devices
and
flows.
Right.
I
think
scoping
it
down
to
the
non-iot
use
case,
makes
it
much
easier
for
a
consumer
of
the
spec,
and
I
think
in
theory,
when
some
of
the
work
dan's
doing
and
others
are
doing
on
iot.
That
could
become
a
parallel
document
that
covers
iot.
I
I
do
think
they're
discreet,
they
can
share,
but
I
think
ultimately,
it's
2022
and
people
still
can't
get
on
the
network
in
under
30
seconds,
with
their
phone
or
their
laptop.
So
to
me
that
should
be
very,
I
don't
think
you
have
to
change
much
of
the
dock.
Maybe
it's
just
the
scoping
in
the
intro
and
even
the
name
potentially.
A
What
what
I'd
like
to
do
with
this
particular
thing
is
not
go
for
an
adoption,
call
right
now,
but
have
a
little
bit
more
discussion
on
the
list
on
the
scoping,
because
I
think
that
would
be
you
know
appropriate
to
make
sure
we
have
the
right
scope.
So
I
I
think
that
that's
what
we
should
do
so
take
it
to
the
list
all
right.
Alan.
C
A
Looks
good
yeah
next,
I
think
we
have
dan
and
dpp.
D
Okay,
thank
you
next
slide.
My
name
is
dan
harkins
and
owen.
Friel
and
I've
been
working
on
this
idea
of
using
the
device
provisioning
protocol,
which
is
it's
a
wi-fi
protocol
that
solves
the
onboarding
catch-22
where
you
you
need
it
credentially
on
the
network,
but
you
need
to
get
on
the
network.
You
get
a
credential,
it's
basically
the
problem
everyone's
been
talking
about,
and
it
does
this
by
gaining
trust
in
what
it
calls
a
bootstrapping
key
and
then
it
uses
this
trusted
public
key
to
authenticate
the
device
and
provision
it.
D
So
we
want
to
leverage
that
same
sort
of
dpp
bootstrapping
key
but
use
it
with
eep.
D
So
the
way
we
do
this
is
we
we
glom
onto
tls
authentication,
using
rc
8773
that
defines
an
external
psk
which
we
derive
from
the
pub
the
trusted
bootstrapping
key,
and
then
we
do
7250
tls
authentication
with
raw
public
key,
so
the
client
can
prove
possession
of
the
corresponding
private
key,
the
the
corresponds
to
the
public
bootstrap
key,
and
then
we
we
have
to
signal
that
we're
doing
this
using
the
extensible
psk's
draft.
So
next
slide.
Please.
D
So
this
is
what
this
is:
the
classic
tls
authentication
exchange
in
the
the
normal
font
is
just
normal,
normal
tls,
the
boldface
stuff
is
what's
added
for
dpp
and
the
red
boldface
is
the
new
stuff.
So
all
we're
adding
that's
new
is
signaling
this
bootstrapping
key
id
other
than
that.
It's
the
same
8773
and
7250
external
psk
and
raw
public
key
authentication.
D
So
next
slide,
please
so
how
this
all
fits
into
eep,
then,
is
we
want
to
do
this
with
teep?
So
what
what
happens
is
identity
response?
The
supplicant
just
says
you
know
tls
poke
or
whatever,
to
signal
that
it
wants
to
do
this
sort
of
authentication
and
then
the
t
exchange
gets
authenticated.
D
With
with
what
I
just
showed
you
in
the
previous
slide
and
once
teep
has
been
authenticated,
we
can
use
the
pkcs107
exchange,
that's
already
in
teep
to
to
provision
a
certificate
on
the
supplicant
and
then
the
supplicants
subsequent
connection
we'll
be
using
classic
tls
with
the
cert.
So
next
slide,
please
so
the
graphs
in
o4.
It
didn't
really
change
much
from
o3,
just
some
minor
editorial
changes.
We
do
have
running
code
and
we're
looking
to
get
rough
consensus.
D
E
Just
very
quick
comment
about
the
a773.
I
think
I
like
that
rfc
and
thanks
for
us
for
the
work,
but
it
was
labor
less
experimental
and
at
that
time
there
were
not
many
libraries
supporting
it.
So
I
wonder
if
that
status
has
has
changed
now.
M
This
is
a
little
experimental,
but
you've
just
heard
about
one
implementation.
That
may
be
enough
to
advance.
M
A
Said
it's
still
experimental,
but
we
may
be
able
to
okay
it's.
I
think
russia
broke
up
a
little
bit,
it's
still
experimental,
but
we
may
be
able
to
move
it
beyond
experimental
based
on
this
case.
Okay,
well,.
K
One
thing
you
mentioned
dan
is
the
use
of
an
identity
response
in
a
way
that's
actually
fairly
common,
but
it's
never
really
been
standardized.
So
very
often,
in
these
kind
of
initial
context,
you
want
to
get
the
server
you
want
to
tell
a
server
you
want
it.
You
want
to
do
something
like
you,
use,
anonymous
or
use
tls,
poke
or
something
else
with
the
intention
of
of
getting
eliciting
a
certain
response
from
the
server
we've.
K
Never
really
documented
these
things,
and
it
might
be
a
good
idea
to
do
it
so
that
at
least
we
get
some
standardization,
but
I've.
N
J
Yeah
I'd
like
to
see
the
strap
move
forward.
J
It
has
the
benefit
of
essentially
providing
an
analog
function
to
what's
what's
already
available
in
the
wi-fi
alliance
for
the
wired
system,
and
it
looks
like
a
pretty
elegant
solution
actually,
and
I
do
think
one
question
that
comes
up
is
once
this
work
is
well
enough
along
right.
We
probably
need
to
do
you,
know
dust
off
the
teep
update
and
get
that
going
again.
J
The
only
we
it
can
be
a
lot
more
narrowly
scoped
than
earlier
attempts,
though
the
the
good
news
there
is
that
we've
seen
a
number
of
the
errata
verified
already
thanks
to
a
couple
of
people
working
on
that
yoni
and
you
know,
roman,
who
did
the
verification
the
last
time
around
and
oleg
pakar,
the
the
only
reason
I
say
we
need
to
open
up.
Teep
is,
I
think,
probably
we
want
teep
to
or
or
maybe
a
rev
of
t
to
reference
this
work.
J
If
we
don't
move
this
forward,
though
we
end
up
with
a
chicken
and
egg
problem,
and
so
I'd
really
like
this
to
move
forward.
D
Yeah
one
regarding
teep
and
referencing
that
can
you
go
back
one
slide
mohit,
please.
So
one
thing
that
I'm
I
kind
of
slyly
avoided
was
the
csr
attributes.
Tlv
doesn't
really
exist
in
teep
yet,
and
I
think
it
really
should
so
yeah.
I
think
they're
a
deep
update
draft
needs
to
happen
and
and
when
we
add
csr
attributes,
then
we
can
reference.
This
draft
as
well.
A
I
think
there's
maybe
some
things
to
resolve
with
tls.
I
don't
know
if
that
I'll
have
to
talk
with
you
and
talk
with
other
chairs
and
see
if
there's,
if
that's
a
blocking
thing
for
this
or
not,
I
don't
think
it
is.
If
it's
not.
I
would
like
to
do
an
adoption
call.
A
I
think
for
this,
because
it
seems
like
there's
a
couple.
People
have
gotten
up
and
expressed
interest,
and
so
is
that
sound,
reasonable
mohit.
E
Yeah
I
joined
the
queue
again,
so
I
am
for
adopting
this.
The
reason
I
joined
the
view
was
basically
as
as
you
as
the
tls
chair
as
well.
It
doesn't
have
to
happen
before
adoption.
It
can
be
after
adoption
to
get
some
like
tls
eyeballs
on
this,
because
I
okay,
it
could
be
wrong
since
I
haven't
read
it
in
a
while,
and
I
couldn't
follow
the
slide
so
closely.
E
There
shouldn't
be
any
issues
with
that,
but
it
would
be
good
to
have
like
more
dls
eyeballs
on
on
this
and
and
that
that
can
happen
after
adoption.
There's
no.
I
don't
know
if
that
would
be
a
blocker,
but
as
the
co-chair
of
the
lsjo,
if
you
could,
like,
I
don't
know,
reach
out
to
the
right
people
to
have
a
look
at
this.
D
So
actually
the
what
our
previous
way
to
do.
This
didn't
use
873.
What
we
did
was
we
generated
a
a
new
elliptic
curve
point
using
the
bootstrapping
key
and
injected
that
into
the
tls
key
schedule
and
when
we
brought
that
to
tls
both
watson,
ladd
and
eric
scorla
said
that
it
was
complicated
and
it
required.
You
know
a
lot
of
heavy
lifting
to
pry
that
into
into
tls,
and
it
was
easier
and
better
to
use
8773
and
7250.
A
A
Okay:
next,
I
think
we
have
mailing
and
eep
ibs.
L
G
L
L
We
should
be
most
concerned
about
use
cases
currently
concise,
2
y
is
used
for
iot
authentication
and
the
other
is
distance
that
not
support
x
find
their
online
certificate.
The
goal
is
to
improve
the
authentication
options.
As
for
the
code,
we
have
implemented
the
prototype
in
2020
for
our
internal
internet
of
things
system.
So
far
we
have
received
some
comments,
both
online
and
offline,
as
I
list
on
the
site,
sister,
ross
and
c
again.
L
This
is
a
simple
example:
eccs
I
used
for
fts
ibs.
The
most
important
thing
is
the
use
of
extensions
server
certificate
type
and
the
current
certificate
type,
which
first
defined
in
rfc7250
to
support
raw
public
king
and
signature
algorithm,
which
defined
in
fc
8446,
but
new
added
in
ef
test
merged
for
signature
selection.
In
my
draft
and
we
wrote
it
identify
basic
nature.
Contents
in
the
certificate
and
certificate
verify
fields,
you'll
see,
ibs
based
raw
public
key
in
ipts
does
not
change
the
message
for
roles
next
slide
things.
L
People
who
have
not
read
rfc6507
in
detail
may
not
exactly
understand
how
the
verification
is
completed
in
this
example.
So,
in
on
this
page,
I
outlined
the
whole
process
prerequisite
it
parameters
several
sent
to
cried,
and
the
current
procedures
for
verification
is
more
detailed
here
than
the
draft
finally
successful
signature.
Verification
means
that
this
identity
has
been
verified.
Nestlight.
L
L
It
is
worth
noting
that
eccsi
is
only
one
algorithm
of
ibs
makes
the
usage
raw
publications
and
x
509
certificates.
It
can
also
be
used
here.
You
only
need
to
specify
the
corresponding
certificate
type,
such
as
their
client
user,
accessing
k4,
kite
authentication
and
the
server
pro
ysn
5
8
0
9
certificate
for
server
authentication.
E
Just
maybe
for
the
benefit
of
those
who
who
haven't,
read
or
followed
this.
If
I'm
not
wrong.
At
least
this
draft
requests
a
separate
method
type
and
doesn't
use
the
same
method
type
number
for
for
standard
etls1
1.3.
So
it
would
be
a
separative
method.
Number.
L
Saying
smoke
it,
but
I
I
think
not
get
your
questions
exactly.
Can
you
speak
slowly
for
me
again,
things.
L
E
Of
the
audience
that
this
will
be
a
be
a
separate
method
number,
but
maybe
now
it's
time
joe,
if
you
want
to
get
a
sense
of
the
room.
A
A
Okay,
so
we
have
I'm
gonna
end
it
in
five,
four,
three
two
one,
so
I
think
did
it
does
it
show
the
result
somewhere?
It
looked
to
me
like
there
were
about
eight
people
that
had
read
the
strap,
so
there
are
some
at
least
some
folks
that
have
read
it.
A
What
I'd
like
to
do
is
maybe
I
think
we
should
have
a
a
call
on
the
list,
since
we
have
people
who
have
read
it.
I
think
there's.
L
Maybe
I
we
can
try
adoption
for
this
draft
because
I
think
this
way
will
push
more
people
to
pay
attention
to
this
merced
and
ibs.
I
think
there
are
many
people
can
help.
O
Yeah,
it's
okay
I'll,
try
to
rush
through
it
yeah.
My
name
is
jan
I'm
currently
for
a
masters
project
looking
into
noob
and
as
part
of
my
my
work
at
the
german
research
and
education
network,
I'm
also
in
the
eduroam
team.
O
So
I
found
this
very
interesting
and
I
have
read
the
draft
and
tried
to
implement
it
and,
while
implementing
it,
I
have
noticed
some
things
about
noob
that
I
just
written
in
this
observations
draft
you
move
to
the
next
slide,
please
so
the
the
first
observation
that
I
made
that
kind
of
puzzled
me
a
little
bit
is
why
use
json
as
the
payload
encoding.
O
I've
seen
some
communication
on
the
mailing
list
why
this
was
chosen,
but
I
had
some
problems
with
implementing
it
because
of
the
kind
of
canonicalization
problems
with
the
json,
especially
for
the
for
the
mac
and
hoop
calculation.
O
The
status
of
the
server
info
and
peer
info
was
kind
of
ambiguous
for
me
because
there
are
some
different
specifications
throughout
the
draft.
Maybe
I
read
the
draft
wrong.
O
Maybe
not
I'm
not
exactly
sure
next
slide,
please
and
the
number
of
messages
exchanged
seemed
to
be
a
little
bit
on
the
high
side,
so
especially
the
the
initial
communication,
where
the
first
message
has
no
information
at
all,
and
the
second
message
is
just
for
communicating
the
the
pr
id
and
the
peer
state
and
one
small
editorial
net,
I'm
quite
new
to
to
the
itf.
So
I
don't
know
if
this
justifies
an
errata,
the
version
is
never
explicitly
set
to.
O
This
is
version
one
they're,
just
example:
values
given
coming
from
that,
but
also
noticing
that
the
method
itself
is
very
good,
and
I
actually
like
the
the
design
principle.
I've
come
up
with
a
new
specification,
eep
utter
user,
assisted
trust
establishment.
If
you
can
move
to
the
next
slide,
which
basically
uses
the
exact
same
design,
principles
as
ibnook
does,
because
they
are
actually
quite
good
from
my
point
of
view,
but
uses
sibo
as
payload
encoding.
O
I've
seen
that
this
was
already
a
discussion
item
on
the
lists
and
was
on
the
agenda
for
possible
version.
Two
of
eb
noob
c-bar
has
some
advantages.
Over
json,
for
example,
I
can
have
the
exact
byte
strings
and
don't
need
to
encode
them
base
with
base64
and
for
using
integers
instead
of
strings
as
map
keys.
I
have
shorter
messages
and
my
current
specification
uses
a
mac
calculation
over
the
whole
message,
so
the
communication
partners
do
not
really
need
to
understand
the
complete
message
or
all
protocol
fields,
because
that
would
possibly
break
extendability.
O
You
can
move
to
the
next
slide
so
for
the
zero
zero
version
of
this
draft.
This
is
a
very
early
draft
version.
I
don't
know
if
anyone
has
read
it
yet.
This
is
part
of
my
masters
project,
so
I
will
develop
it
further
in
the
next
month.
O
I
have
already
made
some
modifications,
I'm
not
exactly
sure
if
I
already
pushed
them
to
the
github
repo,
and
I
have
some
completely
open
questions.
For
example,
how
will
I
specify
the
cypher
suites?
My
idea
was
to
piggyback
on
an
existing
registry,
for
example
the
cosi
elliptic
curves
registry,
but
then
I
have
the
problem
with
what
hash
function
will
I
use?
So
these
are
some
of
the
open
questions
right
now
and
for
now.
My
question
to
this
working
group
would
be:
is
this
something
that
I
should
continue
to
work
on?
A
Okay,
I
don't
think
we
we
have
time
for
questions,
but
certainly
feel
free
to
contact
yan
and-
and
there
could
also
be
some
discussion
on
the
list
on
this
as
well.
E
While
I
opened
the
last
presentation,
just
young,
I'm
obviously
interested
in
the
work,
so
we
can
continue
the
discussion
on
the
list
right.
I
don't
think
it's
max
presenting
it's.
If
you
want
yeah.
P
Okay,
yes,
so
thank
you
guys
and
I'm
glad
that
I
still
have
time
to
present
my
size,
and
I
also
saw
max
join
in
the
chat,
so
feel
free
to
check
me
max
if
you
want
to
leave
any
comments
or
answer
other
people's
questions.
So
today's
my
presentation
is
about
you
know
the
eep
class
overview,
and
this
is
the
method:
well,
a
nip
method
that
that's
used
for
you
know
secured
network's
credential
management
next
slide.
Please
thank
you
yeah.
P
So,
while
we're
working
and
defining
the
architecture
and
also
you
know
the
stack
language
of
you
know
the
sas
network-
and
we
find
that
you
know
automated.
A
credential
management
is
a
very
important
issue,
as
it
may
cause
user
data,
privacy
risks
and
also
the
steps
of
services.
If
misconfigured
and
meanwhile
being
a
typical
sense
network.
P
There
are
different
types
of
credentials
that
may
that
that
need
to
be
provisioned
and
also
managed,
and
that
includes
the
user
level
credentials,
network
and
also
device
levels,
credentials
and
those
credentials
tend
to
be
forgotten
and
remain
to
be
managed
for
quite
a
long
time
due
to
the
possible
operational
and
also
administrative
difficulties
or
the
costs.
And
meanwhile
today's
credentials
management
also
requires
active
configuration
such
as
you
know,
ipa
provision,
fbo,
just
provisioning,
all
the
devices
and
also
the
service
endpoints.
P
So
so
because
we
notice
those,
you
know
the
features
and
challenges
of
the
automated
credential
management
in
the
sas
network,
we
propose
leap
class
as
a
method,
and
currently
the
euclid's
protocol
supports
different
types
of
assessed
networks
already,
and
that
includes
the
world
network,
which
is
you
know,
the
taxes
with
repair
plus
and
also
the
wi-fi
network,
and
also
the
3gbp
network,
and
the
meanwhile
already
defined
the
eep
class
with
the
simple
provisioning
protocol
for
the
cbrsa
network
and
the
documentation
number
is
ts
1003.
P
next
slide.
Please
thank
you,
yeah,
and
here
you
can
see.
This
is
just
offer
you
an
example
of
where
the
security
is
provided.
So
between
the
eep
client
and
also
the
authenticator,
we
will
rely
on
the
max
security
that
could
be
the
nas
in
the
gpp
or
the
bpi
plus
in
dances
and
meanwhile,
between
authenticator
and
also
the
server.
We
will
rely
on
the
application
layer,
security
and
that
could
be
the
tls
and
other
types
of
vpn
protocols.
P
Next
slide,
please
yeah,
and
to
just
to
just
give
a
quick
overview
of
the
upgrades,
so
leave
class
just
provides
a
non-ip-based
mechanism
to
support
mythical
protocols,
credential
management,
and
it
will
offer
offered
the
active
management
and
also
calculation
of
the
device
or
the
network
layer
credentials.
P
And
meanwhile,
we
try
to
keep
the
ip
class
message
flow.
To
be
simple
and,
like
I
said,
if
class
will
just
rely
on
the
security
of
the
external
communication
channels
for
confidentiality
and
basically
in
the
eve
class
protocol,
we
define
three
phases.
The
first
phases
is
the
initial
addition
phases,
where
both
entities
will
exchange
the
credential
configuration,
also
the
information
and
also
the
supported
version
and
the
protocols
and
in
the
provisioning
phase.
P
Both
the
server
and
the
client
will
execute
the
encapsulated
protocol,
such
as
the
simple
provisioning
protocol,
for
example,
and
the
last
phase
is
further
validation,
where
the
server
well
validates
the
ability
for
the
clients
to
correctly
use
the
credentials
before
the
server
claims.
This
is
a
success
of
the
yip
class
next
slide.
Please
thank
you,
yeah,
and
this
one
this.
P
The
this
diagram
just
simply
offers
you
how
you
know
the
message
flow
between
you
know
well,
in
industrial
network
cases
and
also
the
world,
and
also
the
world
network,
and
at
the
above
of
the
if
class,
that
will
be
the
protocol
that
is
encapsulated
in
the
eep
class,
a
payload.
So
in
the
first
cases
of
the
three-speed
network,
that
will
be
the
spp
messages,
for
example,
and
also
in
the
second
case
that
will
be
the
cmp
messages,
for
example,
and
next
slide
these.
P
So
the
next
slide
just
tells
you
that
yeah,
so
this
slider
just
tells
you
that
how
the
class
encapsulate
and
also
decalculate
the
messages
so
epcot
is
leave
base
so
which
means
that
the
abstraction
layer
is
the
base
of
the
class
and
meanwhile,
the
effect
server
will
germinate
the
yip
class
messages
and
it
discalculates
the
payloads
of
the
ep
class
and
then
forward
the
content
of
the
encapsulated
protocol
to
the
corresponding
provisioning
protocols
and
points
and
next
slide.
Please.
P
Thank
you,
so
the
current
status
of
leap
class
is
that
we
already
have
the
ipads
core
internet
draft
available
at
this
link,
and
our
key
focus
now
is
try
to
offer
a
separate
and
independent
id
drop,
which
is
the
eep
class
spp
id
drive,
and
this
new
id
will
just
describe
how
the
snpp
is
is
used
with
the
ubclass
protocol,
and
this
can
be
used
as
a
template
for
supporting
other
protocols
encapsulation
within
class,
for
example,
the
certificate
management
protocol,
and
so
our
goal
is
to
have
the
initial
drafts
ready
for
review
and
comments.
P
And
then
we
will
plan
to
resume
our
activities
within
the
working
group.
And
hopefully
we
can
just
you
know,
continue
our
discussion
and
and
and
with
you
know,
working
group
at
the
next
coming
meeting,
and
we
are
also
currently
looking
for
the
collaborations
and
contributions.
P
So
if
you
are
interested
or
if
you
would
like
to
offer
your
points
or
you
know
comments
or
ask
any
questions,
please
feel
free
to
reach
out
to
us
and
thank
you
and
that's
all,
for
you
know
deep
class
presentation
thanks.
A
Okay,
I
think
we're
just
a
bit
over
time,
so
thank
you
all
for
attending.
Thanks
for
the
presentations
everyone,
I'm
sorry
next
time,
we'll
try
to
get
our
meeting
times
a
little
bit
more
in
line
with
the
number
of
presentations
and
we
hope
to
see
you
either
online
or
in
person
at
the
next
ietf
and
we're
looking
forward
to
everybody's
participation
on
the
list.
Thanks.