►
From YouTube: EMU WG Interim Meeting, 2020-05-22
Description
EMU WG Interim Meeting, 2020-05-22
A
Muting.
Your
microphone
is
good
because
occasionally
there
are
echoes
or
other
problems
that
come
up
for
adding
yourself
to
the
microphone
queue.
We
use
the
WebEx
chat
portion,
which
you
can
find
in
the
WebEx
toolbar.
If
you
do
a
plus
Q
that
will
add
you
to
the
Q,
minus
Q
will
remove
the
Q
and
the
chairs
will
monitor
the
Q.
We
do
have
a
blue
sheet
to
sign
on
the
ether
pad
I
believe.
A
B
A
Yeah,
thank
you
max.
You
know
the
more
that
we
can
get
really.
What
we
want
to
do
is
capture
major.
You
know
any
sort
of
decisions
or
action
items
and
discussion
points
are
kind
of
the
main
thing
we
go
forward
here
and
this
meeting
will
be
recorded
as
it
is
being
now.
I
think
I,
don't
know
if
it
shows
up
anywhere,
but
in
any
case
no
well.
As
always.
This
is
under
the
standard,
IETF
IPR
rules.
You
should
be
familiar
with
this.
This
kind
of
explains
that
you
should
need
to
disclose
any
IPR.
A
That
being
said,
so
here
we
are
virtual
interim
may
2020
interim
for
a
EMU
meeting
over
its
entire
lifetime.
So
this
is
a
historic
event.
We
do
have
an
agenda,
so
I
think
we've
made
it
through
our
administrivia
and
we
have
some
topics
on
TLS
based
EEP
types,
some
update
on
T
Parata,
TLS,
PSK,
aka,
PS,
PFS,
EEP,
noob,
T
brewski,
and
then,
if
we
have
time,
we
had
a
request
for
some
agenda
agenda
time
on
a
pure
configuration.
A
So
if
we
have
time
at
the
end
of
our
agenda,
we'll
do
that
there
has
not
been
a
draft
submitted
for
that
and
it's
not
a
working
group
item,
so
we've
kind
of
as
the
low
priority.
Since
this
is
an
interim
where
we
want
to
try
to
use
it
to
get
our
work
done.
Does
anybody
have
any
comments
or
questions
on
the
agenda?
Yeah.
C
C
Going
to
president
I'm
not
going
to
go
through
the
errata
in
detail,
because
the
person
who
answered
them
Olek
couldn't
be
on
the
call.
It's
you
know
Friday
evening
in
Jerusalem.
It's
not
it's
not
exactly
conducive
to,
but
he'll
he'll.
He
can
make
the
next
one.
Maybe,
but
I
can
talk
about
the
rest
of
the
updates.
Okay,.
A
D
No
a
lot
if
you
want
to
go
to
the
next
slide,
there's
really
only
one
thing
of
actual
content
and
that's
no.
We
seem
to
be
okay.
At
least
one
implementer
major
implementer
I
said
they'll.
Do
it?
The
comments
for
eat
fast
seem
to
be
okay,
but
it
wouldn't
hurt
to
have
someone
else
double-check
that
the
updates
for
teep
are
here
for
now,
because
I
think
the
the
other
documents
are
going
to
be
a
bit
delayed
and
those
have
been
reviewed
and
seemed
to
be.
Okay,
so
I
think
we're
mostly
pretty
good.
D
D
C
This
Elliot
I
apologize
for
taking
the
floor
of
the
I,
don't
have
a
problem
with
Alan
doing
the
deep
update
there
and
then
but,
but
we
should
just
get
to
the
teeth
discussion,
because
there
are
other
issues.
The
one
question
I
have
for
Alan
is
I,
don't
I
looked
over
your
document
and
thought
it
was
really
good
and
I'm
glad
you
wrote
it.
The
only
question
I
had
was:
did
you
handle
the
restart
ntp,
which
is
really
it's
quite
sort
of
linked
to
early
TLS.
A
A
A
C
F
C
An
echo
if
you're,
if
you're
not
presenting,
could
you
mute
okay,
so
great
you'll
notice
that
there's
not
a
draft
update.
Yet
basically,
I
took
the
philosophy
that,
before
we
do,
the
draft
update,
update,
we'd
better,
have
really
good
a
really
decent
implementation
available
of
both
client
and
server
to
try-
and
you
know,
play
around
with-
and
you
know
doing,
that
without
code
is,
is
hazardous
and
I
want
to
talk
about.
Why
all
right,
so
I
started
to
implement
the
pkcs
10.
C
In
fact,
I'm
just
about
done
implementing
the
pkcs
10
packet
format
for
in
teep
it
says
you
can
have
you
can
do
pkcs
10,
you
can
have
a
pkcs7
response,
and
all
this
is
great
but
ok
when
I
went
looked
at
actually
doing
pkcs
10
I
looked
at
the
references
and
they're
actually
calling
for
a
reference
to
Ike,
which
I
think
is
49
five
or
forty
five.
Forty
nine
I
always
get
the
numbers
backwards.
Are
the
RFC
number
and
it's
in
this
one
section.
C
It's
reference
like
six
point,
four
of
this
document,
so
I
go
and
I.
Look
it
up
and
sure
enough.
You
know
yeah
they're
using
enveloped
hem
or
something
that
looks
like
that
right
for
for
pkcs,
ten
formatted
message
to
go
across
L
at
layer,
two
and
I.
Actually
you
know
this.
Is
it's
not
hard
to
implement
this
right?
Openssl
has
all
a
code
to
do
this
and
sure
enough.
C
I
did
it
and
that's
not
so
much
problem,
it's
wasteful
bandwidth,
so
then
I
go
to
implement
pkcs7,
and
the
first
thing
I
discovered
was
that
the
pkcs7
TLD
is
in
pkcs7
it's
CMS
and
that's
because
the
reference
is
to
CMS
down
here
and
the
encoding
is
encoding.
It's
binary
der.
So
for
those
who
are
keeping
track
of
the
situation,
we're
shipping
up
that
on
an
upstream,
a
sort
of
penlight
message
and
downstream
derp
and
the
data
stream
is
supposed
to
be
pkcs7,
because
that's
what
everything's
said,
but
the
reference
is
to
CMS.
C
C
Good,
they
are
on
the
call
I'm
glad
you
joined
just
in
time,
because
I
have
a
question
for
you,
because
you
know
I
literally
discovered.
You
know,
I
discovered
this
yesterday
or
the
day
before,
as
I
was
doing
the
code,
and
my
question
for
you
is:
is
the
envelope?
Is
the
binary,
the
binary
structure
for
a
bag
of
certs
for
pkcs7
different
in
any
way,
then
the
binary
of
the
bag
of
certs
for
for
CMS?
C
C
Okay,
so
absolutely
like
this
format,
I
think
it's
fine,
but
another
discussion
has
been
raised
about
great.
What
do
you
do
when
you
get
one
of
these
things
and
there's
a
sort
of
a
discussion
going
on
in
the
on
the
OpenSSL
list
as
well?
How
do
you
store
these
darn
things?
You
know
don't
worry
about
that
in
the
IETF,
because
it's
not
on
the
wire
but
I'll
just
raise
this
as
something
that
as
an
implementation
issue.
C
F
C
C
F
C
The
other
issue
that
we
ran
into
is
the
request
action
frame.
It's
not
necessarily
the
easy.
It's
not
clear
what
it
means.
To
be
honest:
seventy
one!
Seventy
we
know
what
we
want
it
to
mean,
but
but
it
isn't
that
I
should
explain
what
we
want
and
who
we
is,
but
we
is
Owen
and
I
who
have
been
looking
at
this.
What
we
want
is
a
lockstep
protocol
which
says
where
the
server
can
say:
hey,
client,
can
you
can
you?
Can
you
send
me?
One
of
these
frames
filled
out.
C
One
of
these
people
he's
filled
out.
That's
what
we
want,
but
the
request
action
frame
actually
requires
that
you
send
a
full
TLV,
the
type
the
length
and
the
value,
and
so,
if
I
send
a
if
I
send
a
client
a
request.
Action
frame
that
contains
a
short
length
of
just
the
size
of
the
type
and
no
value
as
part
of
a
request,
action
frame
understand
it
and
it
just
says
that
you
should
process
it.
But
what
does
that
mean?
So
there's
this
this
discussion
here
in
Section,
four
of
seventy
one.
H
C
Should
probably
clarify
this
now,
the
other
possibility
is
oh
heck.
You
know,
yoni
is
already
using
the
request
action
frame
in
context
and
just
as
it's
written,
these
are
cheap.
We
could
just
define
a
new
TLV
for
what
it
is
we
want,
which
is
what
I
just
described,
and
so
that's
one
possibility.
The
other
possibility
is
well
really.
C
So
these
are
the
issues
that
we're
addressing
I
personally
lean
a
little
bit
towards
the
approach
that
we
that
the
approach
that
I
said
we
wanted,
which
is
that
we
would
like
to
say
here,
are
some
some
Ino
types
that
we'd
like
the
client
of
that
we'd
like
the
pr2
back
to
us
completed
and
if
a
camped
and
indicate
the
the
that
then
process
indicate
a
failing
remote
based
on
what
the?
What
the
request
action
frame
tells
you
to
indicate.
I
C
A
Don't
see
anybody
in
the
in
the
chat,
I
think
you
know
they're.
What
I
think
would
help
is
is
to
have
some
discussion
on
the
list
and
like,
if
you
could,
you
know,
describe
the
use
case,
because
it's
not
really
clear.
You
know
there.
There's
I,
think
it's
a
fairly
detailed
discussion
of
what
you're
trying
to
do
and
whether
request
action.
You
know,
as
you
say,
it's
the
right
mechanism
or
not.
If
it
is
the
right
mechanisms,
it
sounds
like
we
should
probably
Claire.
We
should
figure
out.
A
What's
the
best
way
to
address
it,
whether
it's
you
clarifying
the
behavior
so
that
you
can
do
what
you
want,
or
maybe
what
you're
trying
to
do
really
is
something
else.
But
it
sounds
like
it's
fairly
close
to
request
action,
but
I
think
we'd
want
to
have
that
discussion
with
with
the
more
more
detail
so
that
we
can
figure
out
what
what
it
looks
like
so.
C
Joe
I
actually
did
put
a
message
out
on
the
list.
There
were
a
couple
of
hits
of
one
of
those
wonderful
moments
where
Cisco
was
arguing
with
Cisco.
If
you
will
on
this
and
no
we're
not
religious
about
this
either
oleg
or
me
in
terms
of
how
to
resolve
it,
but
we
would
like
some
comments
and
some
thought
on
it.
C
Try
and
do
my
my
Oh
ligament
ation
on
this,
but
there
were
a
couple
of
areas
where
we
know
that
there
were
some
issues
and
and
clearly
the
errata
I
think
all
any
all
of
them
get
to
be
verified
in
some
way,
shape
or
form,
but
just
verifying
them
isn't
enough.
We
have
to
actually
have
the
text
really
clear
on,
but
if
you.
F
C
People
behave
almost
identically
to
eat
TLS
and
occasionally
the
server
will
say
things
like:
okay,
renew
your
certificate
or
okay
we'd
like
you
to
do
a
rat
zest
attestation.
When
that
TLD
gets
defined
right
or
somebody
else
might
want,
you
know,
have
something
else:
they
want
the
client
to
do
that.
C
We
haven't
thought
of
because
you
know
it
just
hasn't-
struck
our
imaginations
yet
we'd
like
that
locks,
lock,
step
approach,
but
on
the
in
the
general
case
you
know
we
still,
we
don't
see
a
need
for
IOT,
at
least
for
there
to
be
an
inner
method.
So
this
msk
issue
is
one
that
absolutely
has
to
get
resolved.
What
and
and
this
further
leads
up
to
the
question
of
given
the
amount
of
changes
that
we're
talking
about,
should
we
bump
the
version
of
teat
as
we
do
these
fixes?
B
Okay,
so
this
is
Mohit
like
we
have
three
different,
deep
related
issues,
so
one
is
of
course,
fixing
the
TTP
data
and
that
that's
of
course,
critical.
Then
there's
the
question
of
how
they're
steep
work
with
TLS
1.3,
and
then
there
is
the
third
question
of
steep
new
usage
of
deep
for
brewski,
IOT
and
and
other
things
and
perhaps
repurposing.
This
request,
action
frame
or
or
defining
a
new
TLV
and
I'm
wondering
like
where
and
how
this
is.
B
All
organized
is
a
little
bit
unclear
to
me,
so
it
might
help
like
for
the
TV
experts
to
sit
down
and
agree
like
we
are
going
to
have
have
two
documents
this
where
this
goes,
and
this
is
where
that
goes
because
I
I
mean
personally
I
think
having
deep
the
7170
with
TLS,
1.3
and
all-day
rata.
Fixed
could
be
one
document,
and
then
these
updates
tea
portion
to
could
be
a
separate
RFC.
C
So,
okay,
two
points
first
to
Tim,
see
thanks
for
further
comment.
I
agree:
we
shouldn't
Jack,
we
what
we
shouldn't.
Do
you
say
you
you
you?
You
must
not
have
an
inner
method
right,
it's
just
that
it
has
to
be.
The
mechanism
should
work
both
for
when
there
isn't
inner
method
and
when
there
isn't
an
inner
method
and
right
now
there's
confusion
about
what
happens
when
there
isn't
an
inner
method,
and
so
that's
that's.
What
needs
to
get
fixed
to
your
point.
C
Is
this
gonna
take
a
while
to
do,
and
so
or
now
his
text
later
on
for
that
for
the
update,
so
my
my
view
is:
let's
just
do
one
document,
because
one
document
is
more
than
I
can
handle
in
terms
of
meet
and
at
least
of
writing
that
I
would
want
to
do
and
let
Allen's
document
continue
as
it
is
with
teep
in
it,
because
if
he's
got
the
the
work
already
done,
why
should
we?
Why
should
we
stop
that
fix
right?
It's
good
work,
let's,
let's
just
keep
going.
B
Yeah
I
mean
the
less
of
the
documents,
the
better
for
me,
I
mean
there's
less
things
to
review,
read
and
send
to
diastema
III
guess
then
my
slight
preference
is
to
even
have
those
one
or
three
update
in
your
single
document,
because
there
isn't
any
way
I
can
implement
tip
with
TLS,
1
or
3
until
I
know
what
to
do
with
there.
So
if,
if
you
want
to
take
the
wall
and
have
it
in
a
single
document,
that's
fine
by
me,
I
was
just
thinking
the
fewer
places.
C
I
think
operations
here
is
first
of
all,
somebody
needs
to
actually
look
at
all
X
message
and,
if
in
either
verify
or
reject
the
errata
right,
because
we
you
know
he's
done
that
work,
if
we
can,
if
we
can
have
those,
if
we
can
have
the
errata
verified
rejected,
discussed
whichever
Jo,
you
did
a
good
round
one
time
if
you
could
take
a
second
pass,
that
would
be
very
helpful.
I'll
commit
to
doing
that.
C
Ok
and
then,
if
yoni,
if
somebody
can
poke
yoni
just
to
see,
if
he's
comfortable
with
all
X
answers,
then
I'd
say
we
have
ourselves
a
ballgame
and
if
those
errata
are
verified,
then
people
can
do
what
they
were.
Gonna
do
with
t
p--
we're
gonna.
You
know
with
the
existing
version
and
use
that
use
that
to
move
forward.
I'll
start,
you
know,
I
have
a
question
in
my
own
head
as
to
you
know,
do
we
bump
the
version
I'm
inclined
to
do
so
just
to
clean
up
some
of
the
some
of
the
text?
C
You
know
how
important
is
that
the
most
important
thing
I
think
is
that
we
get
the
request
action
frame,
correct,
you'll
notice,
I
didn't
discuss
the
Bruce
key
frames.
Those
are
actually
the
easiest
ones
to
do,
because
they're
really
just
piping
through,
but
we
have
to
do.
We
have
other
things
that
we
have
to
look
at
still
with
pkcs
10.
There
are
a
couple
of
like
corner
cases
that
I
didn't
discuss
of
r
instance.
C
There
is
a
form
of
channel
binding
that
is
suggested
in
7170,
which
I
wanted,
which
I
requires
review
as
part
of
this
as
well.
So
I
expect
will
be
I,
expect
I
expect
we
have
a
good
bit
of
work
to
do
in
terms
of
all
of
these.
These
we've
been
fixing
the
just
pqcs
10
and
getting
pkcs7
implemented
and
comfortable,
and
if
we
it
sounds
like
that
would
be
the
the
best
plan
to
go
forward
with
yeah.
B
A
C
C
We
can
call
it
the
the
request
action
frame,
it's
not
necessary
about
the
version,
but
I
think
we
probably
want
to
clean
those
up.
So
that's
really
the
discussion
that
I
think
we
should.
We
should
have
as
we
get
the
drafting
and
it
people
are
comfortable
with
this
way
forward.
What
I'll
do
is
output
forward
a
draft
with
Jim
and
Nancy
and
Owen.
That
really
looks
a
lot
like
the
old
teep
RFC,
but
has
a
lot
of
the
stuff
cleaned
up.
C
Cool
ok
now,
just
before
I
leave
the
floor.
I'll
also
mention
that
when
you
see
that
will
include
the
the
one
of
the
things
that
seems
important,
at
least
for
some
IOT
uses,
is
to
have
a
CSR
attributes
message.
This
is
present
in
RFC,
70/30
and
absent
in
NT
pand.
It's
an
inconsistency
that
we
need
to
clean
up,
and
so
we'll
add
that
as
well
and
then
we'll
look
at
the
brewski
stuff
as
we
go
forward,
but
less
important
than
I
think
getting
T
cleaned
up
a
bit
more.
C
C
C
C
B
That
would
be
me
unless
John
decided
to
show
off
his
own
on
kid
leaf.
So
I
think
I'll
take
the
ball
and
present
so
yeah,
basically
before
the
IETF
that
was
planned
to
be
in
March,
John
I
know,
my
son
Owen
submitted
a
draft
which
basically
doesn't
have
much
content
and
and
only
headers
trying
to
answer
the
question
that
specifies
how
how
to
do
PSK
authentication
with
the
TLS
do.
If
you
can
go
to
the
next
slide.
So.
B
Even
though
RFC
52
16,
which
is
the
original,
if
TLS
specification,
doesn't
explicitly
forbid
PSK
authentication
it,
it
does
say
in
in
section
2
1
1,
that
the
server
must
think
must
include
TLS
server
certificate,
handshake
message
and
a
server
holo
done.
Handshake
message
must
be
the
last
so
kind
of,
even
though
it
doesn't
explicitly
rule
out
PSK.
It
was
implicitly
implying
that
PST
authentication
isn't
supported
and
the
the
updated
drafts
to
work
with
TLS
1.3
now
explicitly
says
that
PSK
authentication
shall
not
be
used.
B
Except
for
assumption,
and
one
of
the
reasons
was
the
comments
from
Bernarda
boba,
saying
that
if
pls
with
certificates
in
is
used
in
many
high
security
applications,
you
know
in
in
the
US
and
and
he
doesn't
want
the
TLS
method
type
to
be
mixed
with
other
forms
of
credential.
So
there
was
a
general
consensus
that
we
do
require
psk
authentication,
but
it
should
be
kept
separate
from
if
TLS
with
certificates
and
that
that
was
the
reason
that
we
saw
this
work
in
an
intercepted
document.
B
If
you
go
to
the
next
slide,
so
why
do
we
need
the
SK
I?
Think
there
there's
I'm
not
going
to
spend
much
time
in
justifying
this,
because
we,
while
we
do
have
EEP
tsk
without
the
TLS,
it
does
not
provide
identity,
protection
and
perfect
forward
secrecy.
So
it's
it's
better
to
like
use
a
modern
protocol
like
TLS
1.3
for
doing
PSK
authentication
and
they
receive
word,
which
is
good.
B
If
you
are,
if
you
have
low,
entropy
user
entered
passwords,
but
it
it
does
require
fake
and
currently
CFR
G
is
running
a
big
selection
process,
so
we
we
should
rather
wait
for
that,
and
at
least
the
e
password
has
some
side-channel
protections
that
may
not
be
suitable
on
IOT
devices.
So
to
counter
these
side-channel
attacks
it
it
requires
some
extra
computation
which
may
not
be
suitable
so
that
the
reason
we
want
to
do
if
TLS,
1.3,
PSK
authentication
inside
deep
as
pudgy,
has.
G
B
That's
true,
so
the
selection
is
done,
but
we
still
don't
have
have
RFC
with
the
actual
fake,
but
yeah
point
noted,
yeah
and
I
think,
even
even
when
we
have
that
we
would
still
want
to
have
a
TLS
PSK,
so
I
think
having
that
big
for
user
entered
passwords
is,
is
fine
and
when
that's
done,
we
can
see
if,
if
there
is
a
need
actually
I'll
I
have
that
on
on
the
next
slide.
So
do
if
you
go
to
the
next
slide.
B
So
when
we
submitted
the
document,
no
yeah,
that
just
fine.
So
no!
No
you
if
you
go
back
once
so
yeah.
So
when
we
submitted
this
document,
there
was
discussion
on
the
list
that
PS
case
and
of
the
only
credential
type
that
that
is
supported
by
TLS.
So,
of
course,
PS
K
itself
implies
whether
you
do
PS
k,
key
exchange
or
PS
k
with
diffie-hellman
for
perfect
forward
secrecy.
Then
russ
has
an
RFC
on
doing.
B
Authentication
with
external
PS
case,
while
also
using
so
certificates,
there's
a
couple
of
individual
drafts.
One
is
on
this
quantum
relief
with
TLS
and
Kerberos,
basically
using
some
form
of
Kerberos
tickets
with
TLS,
and
then
Huntress
has
this
raft
on
Seabourn
web
tokens
in
in
TLS
and
DTLS.
So
the
thing
is
that
if
you
are
going
to
do
a
TLS,
PSK
authentication,
what
about
these
other
variations
of
credentials,
type
that
are
either
currently
supported
by
by
TLS,
1.3
or
may
in
the
future
come
and
yeah?
Now
you
can
go
to
the
next
slide
so.
B
There's
the
question
more
fundamental
question:
before
we
begin
specifying
if
TLS,
1
or
3
PS
case
is:
do
we
only
want
to
do
it
for
PS
k
or
do
we
want
to
have
a
generic
tunneling
method
and
then
any
credential
type
that
TLS
currently
suppose
for
my
support
in
future
is
is
supported.
So
I
listed
pros
and
cons
of
both.
B
On
the
other
hand,
this
this
might
later
come
back
to
bite
us
if
there
is
a
lot
of
new
credential
types
that
are
supported
with
TLS,
including
Seaborg
web
tokens,
then
we'll
have
a
new
if
method
type
for
each
of
them.
So
we
will
have
documents
and
several
method
types
I
mean
we
are
not
running
out
of
the
method
space
yet,
but
that
that's
that's
a
like
question
for
all
of
you
to
answer
what?
C
B
C
We
should
probably
I
mean
I
think
it's
probably
I
would
like
it
possible
for
us
to
track
TLS
right
so
that
you
know
if
somebody
wants
to
use
naked
public
keys,
they
can
and
so
I
think
I,
don't
know
about
everything
under
the
Sun
TLS,
but
adding
back
the
the
support
for
the
naked
public
he's
that's
already
specified
in
TLS
1.3.
That
seems
to
me
to
be
a
very
reasonable
thing
to
do.
C
B
B
G
Think
the
PSK
with
certificates
needs
to
be
supported,
and
it's
you
know
Bernard
doesn't
seem
to
want
to
put
that
in
ETLs,
even
though
I
think
it
meets
the
same
authentication
model
that
is
already
an
EP
TLS.
So
my
question
is:
where
does
it
go?
I
think
the
concerns
that
people
have
about
the
host
quantum
support
is
important.
I
think.
B
We
could
at
least
I
am
open
to
addressing
it
in
this
new
document.
We
are
working
on
I.
Don't
see
any
reason
why
we
we
shouldn't
do
that
I
mean
your
document
is
already
an
RFC.
So
it's
not
like
a
moving
target.
We
know
what
are
the
new
extensions,
so
at
least
I
am
open
to
having
it
in
in
this
document,
so
we
will
do
then
PSK
to
the
Rho
public
key
and
then
PSK
with
certificates.
J
Hi
yeah:
this
is
wrong.
I
just
wanted.
To
reiterate,
I
mean
if
we
have
a
choice
between
what
to
put
in
or
everything
to
put
in
I
would
let
what
the
implementation
community
is
willing
to
write
code
around
Drive,
what
we
do
and
if
we
need
to
make
updates
later.
Let's
do
that,
but
let's
focus
on
the
things
that
you
know.
The
community
wants
to
get
a
bill
tooling
around.
B
A
B
We
have
an
implementation
of
TLS
1.3
with
PS
k.
Of
course
it
currently
doesn't
do
this
PS
k
with
certificates,
but
that's
something
we
can
look
into
doing
doing
that
so
yeah
I
mean
we
have
one
implementation,
it's
it's
only
prototypes,
which
was
basically
to
guide
our
guidance
while
writing
the
draft
so
and
yeah
it's
open
source
and
so
on
so
yeah
some
sounds
good.
I
will
update
the
draft
based
on
the
discussions
here
and
present
it
at
the
next
meeting.
G
A
H
This
is
Yeti,
I
can
also
post
the
link
to
the
death
for
the
new
draft
on
the
chatroom
and
I.
Don't
actually
have
a
whole
lot
to
say.
I
had
one
funny
see
if
I
do
want
to
discuss
it,
a
little
bit
check
your
feedback,
but
from
my
perspective
this
draft
has
been
in
relatively
stable
state
for
a
while,
and
one
issue
that
we
did
have
was
we
discussed
in
ITF
106
was
this
like
there?
H
Should
we
have
more
than
one
algorithms
last
group
slash
curve,
there's
only
one
now
defined
and
and
then
there's
a
question
of
like
how
does
that
get
actually
we're
still
at
these
three
and
without
the
details-
and
you
know
what
is
not
at
that,
what
is
option
and
so
forth.
So
so
in
this
update,
because
I
did
have
to
do
this
week.
Reef
is
just
sake
of
their
ex-partners
trap.
H
You
know
this
is
very
early
proposal
for
the
working
group,
so
it's
basically
sort
of
Stroman
proposal
from
my
side
for
address
for
this
part
of
the
discussion
and
looking
forward
to
your
comments.
Basically,
it
could
be
of
any
nature
like
now.
We
don't
need
this
other
thing
at
all,
or
we
need
specific
number
like
an
one
or
two
or
three.
So
now,
there's
another
one
alternative
thing
and
also
I
can't
claim
that
I'm
at
all
the
details
of
this
list.
H
Or
group-
and
so
it
might
be,
that
my
specification
would
actually
sit
there,
but
the
details
is
wrong.
So
I
request
you
to
take
a
look
and
give
some
feedback
either
now
or
later
again,
the
link
was
in
the
chat
room
and
more
than
I
were
also
struggling
today,
a
little
bit
to
find
accept,
correct
reference
were
P
2,
5
6,
and
so
what
the
draft
actually
ended
up
doing
is
to
refer
to
this
sick
to
version
2,
which
is
from
the
sick
group
that
is
I,
think
no
longer
active.
H
B
A
G
H
G
I
A
Ok,
so
I
think
Elliot
was
in
the
queue
and
then
said
he
what
Russ
said
so
yeah
so
I
haven't
had
a
chance
to
look
at
it
yet,
but
I
think
this
is
you
know
it's.
It's
sounds
like
a
good
addition.
I
would
encourage
people
to
review
this,
because
this
is
one
of
working
group
items
that
we
have
and
we'd
like
to
get
something
out
so
that
maybe
3gpp
could
make
use
of
it.
H
Yeah
and
it's
just
a
sort
of
small
form,
so
my
idea
is
that
perhaps
we
could
just
sold
this
issue
one
way
or
the
other,
and
then
last
such
I
did
have
one
more
question
to
Russ
an
idiot
than
others
who
might
have
opinions
like
I
mean
if
you
happy
with
eat
five
six.
But
do
you
think
one
alternate?
This
is
the
right
number
or
did
you
want
to
have
other
ones
less
long,
I.
G
H
I
I
Basically,
to
kind
of
recall
what
is
the
decide
what
ideas
they
have
been
here
in
the
design?
So
it's
a
EAP
method
with
the
focus
on
bootstrapping
smart
devices
out
of
the
box
without
any
professional
administration
and
the
method
use
there.
Is
this
user
assisted
out-of-band
authentication
such
as
the
user
action
could
be,
for
example,
scanning
a
dynamic
QR
code
or
NFC
tag,
and
I
should
emphasize
that
the
dynamic
tags
are
codes,
not
static,
printed
ones
in
this
protocol
and
in
addition
to
just
authenticating
the
device
once
AP
newb
registers
the
device
to
Triple
A.
I
So
that
was
the
overview
and
then
the
status
of
things.
So
this
shows
the
timeline.
The
latest
action
is
basically
the
working
group
adoption
and
they
were
just
minor
editorial
updates
to
that
version,
and
then
the
next
slides
are
basically
questions
to
you
like
I
know
what
to
do
next.
So,
let's
see
the
next,
or
maybe
there
is
a
status
slide
yeah.
I
So
what
what
I
think
needs
to
be
done
next
is
here
is
some
concrete
things.
One
is
this
same
issue
that
URI
had
that
there
is
just
one
curve
specified
currently
and
one
cipher
suit.
We
know
crypto
suit,
I'm,
not
sure
I
called
it.
It's
called
crypto
suit
in
the
draft,
so
we
have
a
crypto
suit.
That
is,
as
this
curve,
two
five
five
one
nine
and
sha-256
I
guess
I
should
call
it.
Actually.
I
We
should
call
it
X,
two,
five,
five
one,
nine
to
be
pedantic
and
but
when
we
have
only
just
one
crypto
suit,
we
can't
really
test
the
code
for
updating
crypto
suits,
which
is
part
of
the
protocol,
and
something
that
we
spend
a
lot
of
time,
modeling
formally
and
a
kind
of
shown
that
it
should
be
correct.
But
it's
not
been
testing
tested
in
practice
and
there
I
would
be
happy
to
get
suggestions
of
which
curve
to
use.
Is
it
this
P
2,
5
6?
I
I
So
it's
not
going
to
and
just
like
that
and
then
another
detail
is
this
remembering
of
the
protocol
messages,
because
there's
been
some
evolution
over
the
last
few
years
and
in
the
draft
and
the
message
numbering
is
not
exactly
logical,
so
I
think
it
might
make
sense
to
remember
the
messages
before
well,
while
we
can
still
kind
of
get
the
implementers
to
do
it
and
have
them
in
a
logical
order
and
then,
of
course,
the
implementation
needs
to
be
kept
up
to
date.
With
the
current
draft,
which
is
now
again
I
think
going
reasonably
well.
I
I
Do
loop
gotten
it
to
something
that
ends
with
ARPA
and
there's
a
question
tand?
What
name
should
we
use
Lube,
DARPA
or
EAP
new
DARPA,
or
do
we
actually
want
like
a
hierarchical
namespace
for
Lube
EAP,
dr.
Harper
I?
Don't
have
really
an
opinion
on
that,
but
someone
else
might
have
okay.
So
those
are
the
kind
of
questions.
A
B
I
was
just
noting
that
Ross
and
Eduardo
would
like
to
see
p25
six
as
the
second
or
that's
probably
the
sensible
choice.
So
we
should
do
that.
I
think
I
have
been
I
am
still
a
co-author,
but
I
was
only
involved
in
this
work.
Early
on
and
I
have
seen
this
draft
of
also
the
message
numbers
have
gone
from
one
two,
three,
four:
five,
six,
seven
eight.
Then
there
was
a
message:
number
zero
and
I
wasn't
sure.
B
If
you're
going
to
now
add
minus
one
as
the
new
message
number
or
is
it
going
to
be
9,
so
reordering
them
now
makes
sense.
Knowing
that
you
know
at
some
point,
there
may
be
need
for
like
new
new
message
types
but
like
starting
cleanly
now
makes
sense
when
it's
still
not
like
RFC,
yet
I
guess
both
you
and
I
can
help
you
I
can
put
you
in
touch
with
Dioner
to
get
the
EEP
number
not
sure
about
the
nie
I
think
maybe
wrong,
and
our
Joe
have
have
some
opinion
and
I
guess.
B
Ya
is
you're,
saying
that
the
draft
is,
as
Thomas
mentioned,
is
pretty
mature
and
stable.
So
we
can.
This
is
just
a
suggestion.
We
can
ask
for
early
reviews
from
the
security
Directorate
and
IOT
Directorate,
so
I'm
not
saying
we
should
do
last
call
yet
I
think
there's
still
this
message:
renumber
that
should
be
sorted
but
I
don't
see
any
reason
why
we
can't
send
it
to
the
directorates
for
an
early
review.
J
B
B
And
I
think
Elliott
had
put
me
in
touch
with
Wes,
so
I
did
inform
him
about
this
request
for
domain
names
for
both
brewski
and
nuke,
and
this
article
from
the
IAB
is
currently
studying
the
draft.
So
I
guess
we'll
hear
at
some
point.
So
let's
wait
until
we
get
back
answer
from
from
the
IAB
about
this
domain
name,
reservation.
C
On
the
last
point,
what
Roth,
what
was
said
in
particular,
was
that
he
was
not
supposed
to
do
an
early
allocation
of
this
sort
of
thing,
but
shouldn't
in
the
on
the
slide.
I
think
it's
very
likely
that
noob
is
the
first
of
several
methods
that
will
need
this
sort
of
thing,
so
you
know
go
with
the
right
side
rather
than
the
left
side
there.
You
know
in
terms
of
they
want
to
pollute
all
the
dark,
but
space
if
I
was
gonna,
want
to
have
a
simple
name
and
I.
C
B
Yeah
yeah
this
noob
dirty,
but
our
power,
something
that
I
also
suggested
to
the
West.
But
then
he
sent
back
to
me
that
this
would
require
setting
up
the
sub
sub
domain
and
the
loan
for
dot
EEP.
So
yeah
I
don't
have
a
preference
either
win
and
I
agree
that
noob
it's
one
of
several
that
will
request
this
special
use
domain.
So
yeah,
let's,
let's
wait
and
and
see
for
the
IB
to
come
back
to
us
on
on
this.
C
B
J
B
A
F
F
Currently
we
are,
we
I
mean
me
together
with
my
colleague.
Well
we
so
we
are
looking
at
different
IOT
bootstrapping
methods
for
bootstrapping
devices,
resource
consuming
devices
or
simple
device
together
or
together
with
more
resourceful
device
such
as
mobile
phones,
and
we
currently
use
all
the
fan
channel
to
transfer
some
information
which
is
later
used
during
which
is
used
to
secure
bootstrapping
process
through
inbound
channel
and
by
bootstrapping.
We
mean
which
involves
like
pairing
the
device
taking
ownership
of
this
device
and
then
conferring
this
device
to
become
operational.
F
Oh
yeah,
and
we
are
currently
working
on
on
these
kinds
of
these
kinds
of
work
and
what
we
are
looking
at
EAP
is.
Can
we
use
EAP
methods
to
move
this
device
bootstrapping,
including
promises
some
long-term
credential
on
on
the
device
from
from
the
controller
device
itself?
So
so
can
we
have
another
slide?
F
F
So
what
we
are
looking
at
is
like
using
EAP
as
a
mechanism
to
enable
here
configuration
from
from
EAP
authentication
server
which
can
be
used
to
produce
and
credential,
and
the
last
set
some
policies
or
do
some
configuration
on
the
device.
We
are
trying
to
look
at
a
simple
simplest
possible
solution
from
implementation
and
specification
point
of
view.
F
F
This
same,
similar
kind
of
a
responsible
mess
is
flowing
from
server
to
the
peer,
which
will
include
configuration
messages,
and
these
configuration
messages
are
only
to
be
sent
after
completing
underline
EAP
metal,
but
before
sending
the
success,
we're
still
thinking
like
so
this
success
message
should
depend
on
on
the
configuration
response
or
so
that
only
pure
or
or
only
depend
on
yep
it
mattered,
it's
EAP
has
EAP
authentication
has
succeeded
and
then,
even
if
the
configuration
messages
messages
students,
they
still
get
this
success
message.
So
this
is
how
we
haven't
looked
into
into
it.
F
F
So,
before
moving
forward,
we
should
think
consider
some
of
the
issues
that
we
currently
have
like
the
EAP
by
default
does
not
support
this
message.
Fragmentation,
so
the
simplest
way
would
be
to
fit
all
the
configuration
masses
in
there
in
the
single
single
EAP
message
and
there's
this
push
versus
pull
model.
Where
currently
this
there
is
a
request
flowing
from
server
to
the
client.
But
can
we
have
client
requesting
a
configuration
parameter
from?
F
We
think
like
them,
it
could
be
these
following
approaches
that
we
could
use
is
to
simply
define
a
new
message,
type
or
configuration
messages,
and
this
EAP
EAP
request
and
response
messages
that
can
be
sent
the
ID
of
the
direction
or
we
use
currently
EAP
has
this
notification
message
type,
so
we
could
use
this
notification
message
type
to
send
configuration
messages
or
define
some
sort
of
you.
Vap
method
that
use
existing
EAP
turn
any
method
like
EAP
creds
and
also
should
also
think
we're.
F
Also,
thinking
like
there
could
be
another
configuration
protocol
that
will
begin
after
that
is
independent
pap-pap
altogether,
so
EAP
will
only
only
set
the
necessary
things
to
start
another
protocol
after
EEG
system
has
ended.
We
then
need
to
be
a
mechanism
to
compare
it
with
the
both
side
that
there
will
be
another
protocol
coming
coming
and
I'm
thinking
like.
F
Maybe
they
could
be
assessing
by
an
interim
between
ei
pieces
and
then
and
they
another
configuration
protocol,
for
example,
using
some
sort
of
a
derived
and
a
shared
secret
from
maybe
the
APCs,
and
this
could
be
used
to
verify
the
configuration
protocol
that
follow
so
we
are.
We
don't
have
a
ready
draft,
yet
we're
just
here
to
see
to
get
your
viewpoint
on
on
this
matter.
C
First
of
all,
the
one
of
the
reasons
that
the
term
credential
message
is
really
are
they're
broken,
as
you
heard
earlier
earlier,
but
we're
gonna
open
that
document
up
and
clean
that
up
so
I
I.
Definitely
you
know
the
direction
on
fragmentation,
that's
handled
in
the
in
the
TLS
layer
with
teep,
so
you
sort
of
get
that
for
free.
C
C
The
rest
of
this,
you
know,
I,
think
probably
you
and
I
are
probably
within
of
each
other
in
terms
of
trying
to
sort
this
stuff.
If
we
can,
if
we
can
figure
out
the
rest
of
the
discussion
and
for
that
matter,
what
a
long
term
credential
is
if
we're
gonna
open
the
document
up,
for
you
know
broader
discussion,
we
can
certainly
open
it
up
to
that.
Commit
to
that
question
as
well
and
would
be
interested
in
maybe
working
with
you
on
that
as
we
move
forward.
I
I
wanted
to
comment
on
the
push
and
pull
a
question,
because
the
way
I
understand
it
is
there
is
kind
of
you
can
have
two
kinds
of
device
configuration.
One
is
a
kind
of
DHCP
type
request
where
the
device
has
an
opportunity
to
ask
for
specific
configuration
options,
and
then
the
server
responds
to
that,
and
then
there
could
be
just
kind
of
push
where
the
server
just
tells
everyone
announces
well
to
the
device.
What
is
your
configuration
here?
It
is.
B
Yes,
so
I
think
my
general
suggestion
is
as
little
changes
to
Eve
as
possible
for
doing
what
you
want.
So
if
it's
yeah
I
mean,
perhaps
you
could
look
at
tip
as
well,
but
if
you
want
to
configure
other
types
of
credentials
or
then
either
like
one
or
or
three
is
better
like
I,
don't
want
like
protocols
like
Acme
and,
like
many
other,
these
provisioning
CMS
CMC
all
that
running
over
eeep,
because
heap
is
often
running
over
over
the
link
layer.
B
B
So
it
provides
you
like
if
but
then
also
doesn't
like
tightly
couple
the
provisioning
protocol
with
the
authentication
protocol
except
the
key
or
then
one
of
the
option,
one
of
this
defining
new
message
type
so
that,
like
new
implementations,
that
support
this
message
type
would
do
what
you
want
to
do.
But
as
these
existing
implementations
are
like
not
broken
or
don't
have
to
change,
yes,.
B
So
my
suggestion
would
be
to
think
of
what,
if
method,
are
you
going
to
use
for
the
actual
authentication
and
then
see
whether
that
EEP
method
allows
you
to
send?
Whatever
is
the
information
you
want
to
set
so
like?
Is
there
some
field
in
that?
If
method
that
allows
you
to
send
some
some
small
configuration
data
that
will
be
used
in
a
separate
protocol,
but
without
like
deciding
on
on
the
way
on
which
each
method
is
used
for
authentication
it,
it
becomes
a
little
bit
harder.
Then
that's
only
a
suggestion.
C
C
C
When
you
start
to
point
to
things
that
are
outside
of
II,
when
you
start
to
do
that
binding,
then
you
have
to
do
the
binding
a
across
sessions
he
potentially
across
devices,
and
so
you
you
you,
you
can
introduce
a
lot
more
complexity
in
actually
not
putting
stuff
into
EEP.
So
we
should
be
careful
about.