►
From YouTube: IETF115-EMU-20221107-1530
Description
EMU meeting session at IETF115
2022/11/07 1530
https://datatracker.ietf.org/meeting/115/proceedings/
A
B
B
Yeah,
we
also
have
masks
up
front
if
you
need
one,
but
it
looks
like
everybody
here
already
has
one
just
want
to
remind
people
of
the
note?
Well,
if
you've
been
at
an
ITF
before
you
should
be
familiar
with
this,
if
not,
you
should
get
familiar
with
it.
It
talks
about
various
things,
behavior
and
IPR,
and
things
of
that
nature.
B
So
next
slide-
and
here
we
have
an
agenda
I
believe
we
have
a
note
taker
already,
although
if
you
want
to
join
and
and
the
notes
are
on
in
the
agenda,
there's
a
link
to
the
Edge
yeah
hedge
dock,
where
we
take
notes,
it
would
be
great
if
there
were
some
people
who
were
joined
to
zulip.
So
we
can
reflect
any
comments
that
need
to
be
made
in
the
room
at
the
mic
and
I
talked
about
the
on-site
tool.
B
So
please
scan
that
barcode
and,
if
you're
on
site,
so
that
you
can
join
the
queue
as
well.
B
Let's
see
is
Yari
here
he
had
asked
to
go
earlier,
but
perhaps
he
too
does
not
need
to
go
early,
so
I
know
Elliott
could
not
make
it
early
for
the
bootstrap
PLS.
So
we're
going
to
move
that
to
the
end,
and
hopefully
he'll
will
be
here
before
that
time
comes.
If
not,
we
can
give
a
short,
possibly
a
short
update
on
that.
B
So
does
anybody
have
any
additions
or
modifications
to
the
agenda?
If
so,
please
speak
now.
B
If
not,
we
should
go
to
the
certificate
issues
and
have
Alan
give
us
a
little
introduction
to
that.
C
Yeah
afternoon,
on
there
we
are
next
slide,
so
we've
had
a
bunch
of
discussions
over
various
meetings
about
certificates
and
Eep.
C
The
question
is
what
to
do
next.
These
documents
discuss
some
configuration
via
certificates,
onboarding.
C
D
C
B
You're,
just
looking
for
discussion
so
yeah
just
to
kind
of
set
the
stage
here,
we're
talking
about,
say
for
an
EP,
TLS
connection,
there's
kind
of
two
two
sides
here:
there's
the
the
server
and
then
there's
the
client
or
or
are
you
most
concerned
about
how
we
trust
the
server
or
are
you
talking
about
how
we
provision
the
client
as.
C
Well,
everything
so
for
those
of
you
who
are
in
the
radius
group
similar
issues
there,
how
do
you
get
certificates?
How
do
you
provision
them?
How
do
you
manage
them?
What
does
it
mean
when
you
connect?
Do
you
do
server
name
indication?
Do
you
do
CA
indication
what
problems
are
people
running
into
I've,
put
some
ideas
into
the
various
documents
but
I'd
like
to
know
if
people
read
them
have
more
opinions,
and
then
we
see
where
we
go
from
there.
B
So,
in
particular,
like
I,
think
we've
all
seen,
and
even
at
this
meeting
here
very
often
the
authentication
of
the
server
certificate
comes
down
to
somebody
clicking
a
box
saying
oh
yeah
I
want
that
one
and
very
often
they
they
don't,
have
the
information
to
actually
know
if
they're
doing
the
right
thing
or
not
and
I.
Don't
know
that.
There's
particularly
a
great
solution
for
this
I.
B
Don't
know
if
edurome
folks,
if,
if
you
have
kind
of
a
solution
to
this
problem
or
if
it's
or
if
it's
still
a
problem
in
in
your
deployments,.
E
E
Yeah
at
your
own,
so
a
twofold
answer
to
this
one
is:
we
very
much
suggest
the
use
of
onboarding
tools
which
push
the
entire
each
configuration
to
the
client
device,
including
the
series
to
trust
all
fingerprints,
all
things
you
need
and
we
try
to
make
it
almost
impossible
not
to
use
that
there's
a
couple
of
ways
to
do
that
with
tricks
in
the
methods
and
so
on,
but
there
is
also
a
movement
we've
done
in
the
Wi-Fi
Alliance,
which
has
now
forbidden
the
Do
Not
validate
server
certificate
option.
E
So
if
you
got
a
reasonably
new
client
like
Android
12,
it
will
not
just
let
you
get
away
with
saying:
I,
don't
care.
The
option
has
just
gone
away
and
it's
tested
to
be
not
there.
That
was
one
thing.
The
other
way
to
do
this
in
each
is
when
the
radius
and
EPS
server
only
accepts
requests
from
a
specific,
weird
username
as
the
outer
identity.
So
if
you
just
click
on
a
network,
don't
configure
anything
yourself,
then
you
would
just
use
the
inner
equals
outer
identity
and
the
server
would
recognize.
B
So
but
when
so,
when
you
do,
you
say
you
require
configuration
to
be
pushed
to
the
device.
Now.
Is
that
configuration
just
like
in
in
your
world?
How
is
the
certificate
you
know
a
CA
hierarchy
and
naming
done
like
so?
Is
there
a
single
hierarchy
that
all
servers
have
an
issue,
or
do
you
have
a
series
of
certificates
in
a
bag
of
certs
or
how
does
that
work.
E
So
the
choice
of
server
certificate
is
a
per
IDP
or
a
realm
of
choice,
so
we
don't
have
any
particular
requirements.
So
many
idps
choose
to
use
a
commercial
CA
and
rotate
the
server
certificate
within
that
trust
chain.
Every
year
others
choose
to
deploy
a
private
CA
special
purpose.
Ca
just
write
your
own
purposes
with
longer
lifetimes
and
so
on,
and
some
even
just
have
a
self-cent
certificate.
E
C
I
I,
don't
know
why
that
would
ever
be
a
good
idea,
but
I
guess
pushing
that
through
the
Wi-Fi
Alliance
and
you're
forbidden
from
doing.
That
is
a
good
idea
and
also
the
automatic
configuration
is
a
big
step,
but
I
guess
this
is
this
may
be
more
for
operators
than
implementers.
C
What
issues
are
you
having
with
certificates,
because
I
I
hear
some
I've
put
some
ideas
in?
But
if
there's
more
and
more
requests
it'd
be
good
to
get
that
in
a
document.
G
Hi
everybody
good
morning
good
afternoon
from
Colorado,
so
I
just
wanted
to
so
in
our
in
our
industry,
so
I
work
for
cable
lab,
so
in
the
cable
Broadband
industry.
One
of
the
problems
that
we
have
and
we're
trying
to
address
is
actually
managing
all
these
different
type
of
credentials
that
devices
have
and
out
on
our
networks,
and
usually
these
credentials
are
not
really
managed
right.
G
So
one
of
the
problems
that
we
found
is
that,
especially
when
you
come
in
this
can
be
extended
to
iot
type
of
discussion
where
there's
one
set
of
credentials
that
is
used
to
access
the
network
and
there's
another
set
of
credentials
for
user
level
type
of
applications,
usually
the
first
set,
is
always
forgotten
right.
So
it's
my
home
connection
or
is
something
that
I
don't
really
don't
care
about,
because
I
only
care
about
my
credentials.
However,
these
are
very
important.
G
You
know,
as
we
know,
you
know,
compromised
devices
can
really
lead
to
disastrous
issues
like
botnet
cetera.
G
So
one
of
the
things
that
we
are
we
worked
on
in
some
environments
and
we
are
trying
to
to
bring
also
here
is,
you
know,
managing
actively
managing
these
credentials
and
if
for
us
seems
to
be
a
very
a
very
useful
Paradigm,
because
we
don't
want
to
have
to
provision
all
the
tcpe
ETC
and
then
do
all
this
this
thing,
but
doing
before
devices
have
any
access
to
our
Network
so
that
we
provision
we,
we
manage
these
credentials
and
we
only
give
access
after
we
manage
the
credentials
or
we
evaluate
that.
G
So
for
us
it's
definitely
there's
a
very,
very
important
use
case.
We
have.
We
did.
We
propose
an
approach,
that's
called
epcrads
that
we
already
standardized
in
cbrs
and
we
would
like
to
continue
to
work
on
this.
We
were
not
ready
at
this
ITF
because
of
additional
work
in
other
work
groups,
but
definitely
we
want
to
continue
the
the
the
consideration,
because
we
think
it's
really
really
important
to
have
some
kind
of
solutions
and
and
think
about.
Also
in
this
you
know
from
operator
standpoint
of
view.
G
Now
we
have
different
types
of
networks
as
well,
so
we
have
from
3gpp,
Wi-Fi
and
and
wired,
and
they
all
have
different
provisioning
mechanisms,
different
validating
mechanism,
so
having
something
that
you
know,
mechanism
that
we
run
on
it
that
we
can
use
to
really
bring
together
this
managing
of
all
these
type
of
credentials.
This
type
of
networks
for
managing
this
is
very
specific
for
managing
network
access
credentials,
so,
for
our
use
case,
is
very
specific
not
to
manage
everything
just
very
specific
ones.
G
Does
that
working
the
the
action
that
you
were
thinking.
C
Yeah
anything
can
make
this
easier
for
people
and
it's
just
a
matter
for
the
certificate
issue,
specifically
just.
H
A
Yeah
hi,
this
is
from
radiator
software
I.
Think.
Maybe
one
topic
of
discussion
is
that
how
to
separate
these
different
problems
with
certificates?
If
we
think
about
let's
say
radio
server
certificates,
they
are
kind
of
I,
don't
see
a
lot
of
problems
with
with
them.
The
most
most
of
the
problems
is
related
to
that
that
organizations
they
don't
remember
to
renew
their
certificates,
and
this
can
be
handled
with
something
like
automation
like
let's
encrypt
or
something
like
that.
A
So
that's
a
kind
of
a
solo
Apple
issue
and
it's
not
a
kind
of
a
very
important
one.
But
then,
when
we
have,
this
kind
of
device
is
with
end
users
who
don't
have
the
connection
to
the
actual
authenticator
to
IDP
there,
and
it
would
be
needed
to
okay
give
it
these
users
and
devices
a
certificate
and
the
Liberty
devices
are
not
under
any
mobile
device
management,
a
kind
of
a
providing
a
certificate
to
those
devices.
A
Those
users,
that's
the
hard
part,
because
the
users
may
not,
for
example,
like
to
install
Ado
ROM,
cut
this
kind
of
a
configuration,
a
tool.
They
would
just
rather
take
something
like
coming
from
the
web
server
or
something
like
profile
tear
and
with
this
kind
of
approach,
there
are
security
issues
that,
for
example,
with
iPhones
you
can
get
all
kinds
of
nice,
let's
say
profiles
and
some
of
the
malware
app
stores
operate
just
like
this,
so
that
they
offer
a
profile
for
users
to
install,
and
then
the
device
is
kind
of
owned
there.
A
So
this
kind
of
way
to
provide
those
client
certificates
to
the
devices
that
users
who
are
not
kind
of
part
of
the
let's
say,
identity
domain
or
the
identity
provider
service.
That's
the
kind
of
a
let's
say,
hard
issue
to
tackle
of
it.
C
I
E
So
one
of
the
actual
complications
with
EPS,
of
course,
that
you
use
Eve
often
to
get
network
access,
so
you're
offline,
so
we're
always
torn
apart
between
these
onboarding
tools,
which
can
be
distributed
offline
and
you
just
run
them
and
they
work
versus.
You
have
to
contact
some
server
to
fetch
your
configuration
from
and
yeah
both
have
their
ups
and
downsides.
So
far,
we've
always
been
using
offline
tools,
but
those
are
less
convenient
than
just
going
to
a
website
clicking
your
configuration
together
and
so
on.
C
Yeah,
so
so,
some
of
what
I've
I've
discussed
in
the
documents
is
about
that
specific
kind
of
thing,
one
of
which
is
realistically
speaking,
most
devices
have
two
kinds
of
network
access.
You
know
your
phone
has
a
3G
backhaul.
So
if
you
want
to
get
on
Wi-Fi,
you
have
a
way
to
get
to
the
corporate
website
or
your
laptop.
Well.
If
you
can't
get
on
the
corporate
Network
at.
D
C
C
J
C
K
On
magically
get
on
the
network
right,
so
so
we're
talking
devices
that
are
reasonably
capable
devices.
Yes
and
you
don't
want
to
run
down
the
rabbit
hole
of
saying
just
go.
Do
5280
right!
That's
the
cert!
That's
this!
Is
it
5280
or
36,
70
47
it
that
those
are
the
those
are
the
pkx
documents
you
don't
want
to
do
that
right,
I
mean
that's
a
rabbit
hole.
K
L
C
I
forget
which
one
this
is
XML
configuration
which
is
has
all
of
that,
including
which
eat
method
to
use.
That
typically,
is
not
in
the
search.
K
C
You,
yes,
realistically
speaking,
everyone
who
almost
everyone
lots
of
people
who
have
Wi-Fi.
C
K
So
the
problem
there
is
you're,
then
adhering
to
the
cab
form
rules
of
trust,
store
rules
which
leads
you
down
a
little
different
path
right,
which
you
don't
necessarily
care
about.
I,
don't
I,
don't
think
shoot.
What
was
I
going
to
ask?
Oh
so
public,
Cas
versus
private
CA
sounds
like
you
got
a
mix
yep.
You
do
both
in
a
case
where
you
do
private
cas
es
easier
because
you
can
install
the
trust
stores
yourself.
K
K
Sorry
I
didn't
announce:
myself
did
I
so
I'm
Doug,
Cooley
I'm
from
NSA,
but
I
work
in
the
CSD
piece,
so
public
cdas
or
private
Cas.
They
both
have
their
issues,
but
that's
two
little
sets
of
things.
You
have
to
do
right
that
are
going
to
be
different,
because
if
you're
doing
public
ca's,
you
don't
have
to
manage
the
trust
store,
like
you
do,
with
a
private
CA.
K
C
C
C
K
K
C
If
you
believe
certain
certain
discussions
and
certain
yeah
suggestions
about
what
the
cab
Forum
rules
are,
every
MTA
that
uses
a
cab
Forum
certificate
should
have
their
CA
banned,
should
have
their.
C
Certificate
band,
but
if
the
ca
continues
to
issue
those
certificates
have
it
banned
because
there's
a
certain
opinion
that
the
cab,
Forum,
Cas
and
certificates
are
only
for
use
with
TLS
webs
web.
C
There's
an
Eep
onboarding
draft
and
there's
a
configuration
draft
that
I.
If
you
look
for
my
name,
you'll
get
them.
K
K
C
Using
TLS
web
server
certificates
and
situations
where
they
are
forbidden
seems
to
be
an
issue.
The
fact
that
nobody
cares-
and
nobody
does
anything
is
annoying.
But
you
know
my
two
cents
is
hey:
if
I
can
go
War
driving
around
the
planet
and
find
all
these
certificates
used
in
invalid
locations
and
report
them
and
kick
everyone
off
of
corporate
Wi-Fi
worldwide,
that's
a.
K
B
C
Yeah,
so
this
is
this
is
my
my
sort
of
finger
in
the
air
proposal,
for
example,
does
provisioning
overteep
as
an
Eep
implementer
I,
really
dislike
re-implementing
IP
over
Heap?
It's
not
quite
IP,
it's
not
quite
bulk
data
transfer,
but
it
could
be,
and
it's
just
it
just
smells
to
me.
C
On
the
other
hand,
if
you
say
unauthenticated
epls,
my
username
is
at
eat.arpa
whoever
you're
authenticating
to
goes
oh
I'm,
going
to
put
you
in
a
quarantine
VLAN
you
can
get
to.
You
know
the
corporate
web
server
authenticated
via
your
existing
Cas
web
Cas.
C
Oh
look,
there's
files
there
saying
how
to
download
things
and
how
do
you
configure
yourself
for
the
actual
Eep
configuration
downside
with
this
is
DNS
web
people
are
in
a
different
organization
than
the
radius
people,
and
if
you
talk
to
the
various
vendors,
they
say
that
is
very
often
a
hard
requirement.
You
cannot
have
radius
or
Eep
make
restrictions
in
other
people.
So
it's
a
solution,
but
not
administrative.
H
C
E
So,
as
we
talked
about
peacocks
going
down
the
peacocks
route
and
client
certificates
just
to
clarify,
there
is
a
growing
understanding
in
our
community
that
passwords
are
on
the
way
out.
So
there
are
also
some
deployers
that
chose
to
send
you
to
a
website
authenticate
with
your
web
credential,
which
could
be
a
Fido
key
or
well
still
the
best
one.
E
If
you
don't
care
and
issue
you
a
client
certificate
for
the
Wi-Fi
purposes,
for
the
purposes,
which
has
the
advantage
that,
since
you
have
to
download
the
client
certificate
anyway,
you
can
just
in
the
same
moment
also
be
forced
to
download
the
whole
configuration,
including
the
server
software
validation.
So
yet
the
same
package
that
you
would
get
if
you
were
to
use
a
simple
password-based
method,
but
now
you
have
into
your
list
inside
rather
elegant,
but
again
you
need
online
support.
E
C
E
I'm
going
to
say,
I'd
love
to
but
Fido
and
web
often
is
something
I
look
into
myself
and
the
issue
is
that
every
time
you
authenticate
you
have
to
be
validated
for
being
present
at
the
device.
So
you
have
to
put
your
finger
on
something
for
Wi-Fi.
This
is
exactly
not
what
you
want.
A
Yeah
some
some
notes
about
these
different
things.
One
that
was
maybe
not
mentioned
here-
is
that
some
of
the
devices
they
have
they
used
to
have
this
kind
of
common
certificate
store.
So
they
don't
have
a
certificate
store
per
the
functionality,
so
they
have
a
common
certificate
store
for
web
for
Wi-Fi
and
for
application
installation.
A
So
when
you
install
a
root
certificate
to
this
kind
of
devices,
you
can,
after
that,
install
also
any
any
kind
of
functionality
for
those
other
things
there
as
well,
so
that
is
kind
of
incredibly
being
solved.
The
devices
now
have
Android
devices
other
devices.
They
have
the
different
certificate
store,
so
it's
being
installed
by
the
vendors
there
and
then
a
comment
about
the
those
TLS
server
certificates
for
web
yeah
and
I.
Both
know
that
they
are
being
used
used
in
the
organizations
they
use.
A
A
I
recently
had
this
case,
where
customer
had
their
TLS
server
certificate
expired
and
fun.
Eating
in
that
is
that
only
those
devices
that
were
wrongly
configurate
not
to
check
the
certificate.
They
were
perfectly
because
the
server
certificate
had
kind
of
expired,
but
all
those
devices
that
were
configured
properly
they
just
stopped
functioning
because
that
several
certificate
had
kind
of
a
expired.
C
And
the
related
point
to
that
is:
I
have
my
wonderful
device
with
huge
amounts
of
CPU
power,
a
really
big
screen
and
when
something
goes
wrong
with
Wi-Fi
authentication,
I
get
failed.
What
failed!
Why
was
the
certificate
invalid?
Which
certificate
was
presented
right?
What
what
what's
going
on,
and
the
answer
from
the
vendors
is
too
bad?
Go
away?
We're
not
telling
you
yeah.
J
J
I
think
also
one
one
thing
that
that
we
need
to
take
in
account
is:
how
do
the
devices
know
which
server
name?
They
should
trust
I
mean
if,
if
we
have,
for
example,
Android
has
the
the
option
to
just
use
the
the
system
certificate
store,
which
is
great
at
least
I,
have
now
some
authentication,
but
still
I
have
the
the
problem.
How
does
my
device
know
that,
for
my
at
Uni
minus
bremen.te
account
the
certificate
name
should
be
radius.velan.uni
minus
bremen.de?
That's
that's
something
that
I
have
to
configure.
J
So
if
we
we
don't
or
we
can't
stop
at
the
stage
where
we
have
certificates
and
Cas,
and
we
can
somehow
determine
that.
But
we
also
have
to
look
at
the
contents
of
the
certificate
and,
for
example,
it
would
not
be
good
or
possible
in
some
settings
to,
for
example,
use
uni
minus
bremen.de
as
a
common
name,
or
something
like
that,
because
of
course
then
the
if
I'm
the
the
radius
operator.
For
that,
then
the
webs
people
will
kill
me
if
I
have
a
certificate
for
uni
minus
bremen.de,
because
I
could
use
that.
C
B
My
question
is:
do
in,
are
there
any
work
in
the
Wi-Fi
Alliance
that
covers
this
type
of
thing?
At
all,
does
anybody
know
I
know
there
were
some
brief
stuff
previous,
but
I've
lost
track.
L
E
Yeah
there
is
a
draft
from
the
ITF
which
I
wrote,
which
I
expired
like
seven
years
ago
or
so,
which
specifies
all
the
details
you
might
need
to
properly
set
up
deep
so
that
you
could
vendor
agnostic,
just
push
these
two
devices
and
don't
know
what
to
do.
It
got
zero
attraction
in
iitf
and
every
device
vendor
has
their
own
file
formats
to
express
that
kind
of
detail
and
as
I
approached
Wi-Fi
lines
with
this,
the
answer
was
basically
every
vendor
has
their
own
thing.
Interop
is
not
needed,
so
nothing.
B
Yeah,
so
I
guess
so.
Alan
has
a
couple
drafts.
How
many
folks
have
have
looked
at
those
drafts,
the
bootstrapping
and
the
configuration
draft
couple?
What
what
I
think
we
would
like
to
do
is
have
a
few
more
folks
take
a
look
at
these
and
I
guess.
One
sense
here
is,
it
seems
like
there.
This
is
an
interesting
topic
for
for
people
in
emu.
Is
there
anybody
who
thinks
this
is
not
a
good
topic.
D
Yeah
go
ahead,
somebody
so
just
kind
of
a
note.
What
what
actually
such
suggested
right
is
that
you
temporary
gets
authenticated,
although
you're
not
right,
and
that
may
be
fine
except
that,
for
example,
rise
of
we
are
using
that
that's
called
like
the
guest
flow
right,
so
you're
getting
the
authenticated,
then
you're
doing
the
viable
syndication
for
example.
Then
you
get
pre-authenticated
so
and
that's
not
fine!
That's
not!
Okay
for
everybody.
Just
people
explicitly
says
that
no
we
are.
D
B
So
can
you
just
say
your
name
for
the
note
taker.
B
Yeah
so
I
think
we
should
take
this
to
the
to
the
list
and
try
to
have
a
bit
more
of
a
constructive
discussion
to
see
what
exactly
we
want
to
do
here.
Is
it
a
set
of
recommendations?
Is
there
specifications
that
we
should
do,
because
clearly,
there
is,
is
a
gap
all
right?
What
I'd
like
to
do
is
oh
John,
Friedrich
Do.
You
have
a.
J
Yeah,
just
just
a
quick
comment,
I
think
the
the
interesting
question
we
should
also
ask
ourselves
is:
should
we
push
forward
for
methods
that
assume
we
have
a
second
Channel,
or
should
we
try
to
also
look
into
in-band
things
where
you
have,
for
example,
through
certificate
options,
well
pray
to
the
ca
browser
Forum,
an
implicit
definition
of
whether
or
not
to
trust
the
certificates?
So
I
think
that's
just
as
an
as
in
question
that
we
should
discuss.
B
Okay,
Yuri
you're
here
and
I,
think
you
have
a
limited
time
frame.
So,
if
you'd
like
to
come
up
and
present,
that
would
be
great.
I
All
right,
so
this
is
brief.
I
think
I
wanted
to
provide
an
update.
So
this
is
the
forward
secrecy
draft
that
we've
been
working
on
next
slide,
please
so
the
sort
of
high
level
draft
statuses
that
we
had
some
discussion
in
the
previous
idea
for
some
issues
that
we
wanted
to
resolve.
I
We
did
that,
although
that
was
sort
of
closer
to
this
meeting
than
the
last
meeting,
at
least
from
our
first
point
of
view,
there
isn't
any
opening
Series
at
the
moment
there
hasn't
been
much
discussion
on
the
list.
I
think
we
had
previously
sung
because
there
was
yeah
technical
questions.
I
I
haven't
seen
much
recently.
We
also
had
some
discussion
in
3gpp
that
was
a
while
ago,
and
but
that
was
more
like
a
review,
and
you
know
my
Ultimate
Dream
is
that
we
can
make
something
like
this.
A
mandatory
thing
in
even
in
3gpp-
that's
not
gonna
happen,
probably
right
away
and
in
some
pushing
from
various
operators.
I
So
there's
no
sort
of
3tbp
link
to
this
directly,
but
we
do
sort
of
from
a
private
discussions.
Have
some
operators
who
are
actually
quite
keen
on
working
on
this
sort
of
from
yeah
disturbing
customers
with
sensitive
needs
and
so
from
a
vendor
perspective?
At
least
we
would
like
to
get
this
done
and
get
get
it
published
so
that
we
can
actually
have
a
final
spec
with
every
everybody
can
build
too,
and
let
me
gets
us
go
go
do
this.
I
I
So
what
were
the
changes
in
in
08?
You
can?
You
can
look
at
the
detailed
div,
but
at
the
high
level,
so
we've
been
going
sort
of
reviewing
a
little
bit
the
the
algorithms
over
several
versions.
Like
you
know,
we
aligned
exactly
here
and
there
and
are
we.
You
know
pointing
to
the
right
places
and
so
forth.
I
We
made
one
more
change
in
distribution.
That
was
that,
basically
in
3cpp
they
have
a
facility
for
protecting
the
identity
of
the
user
connecting
to
the
network
and
it's
the
3gpp
sub
key
and
the
the
they
actually
require
two
algorithms,
p256
and
and
and
the
x255
19
both
are
mandatory
there.
So
we
aligned
with
that
for
for
this
trackable,
which
I
think
makes
sense.
I
I
What,
then,
who
defines
what
and
what
are
the
rules
in
combining
this,
and
we
wanted
to
actually
specify
that
in
detail
for
future,
so
that,
like
now,
it
says
what
governs
what
and
what
you
need
to
do
if
you
define
one
of
these
things
going
forward,
yeah
some
minor
clarification
of
the
key
calculations
in
section
6.3,
basically
adding
some
validation
requirements
and
keeping
the
two
algorithms
sort
of
descriptions.
Textually
separate.
I
We
added
some
security
considerations,
discussions
two
items
in
particular
one
on
the
quantum
Computing
attacks
and
like
Okay,
so
this
becomes
possible
in
practice.
What
then
how's
this
specification
updated
or
impacted?
Excuse
me.
We
also
have
a
discussion
of
what
you
know.
What's
the
impact
of
metadata,
and
you
may
ask
what
is
this
meta
that
you
speak
about?
I
Well,
it
does
not
match
and
we're
not
sending
super
relevant
information,
but
there's
some
algorithms
and
so
on
that
get
sent
as
part
of
the
EAP
AKA
exchange
and
if,
if
you
were
to
depend
on
on
the
user's
identity
in
selecting
those
algorithms
for
for
whatever
response
you
you're
making
that
you
might
actually
leak
some
some
information,
so
that's
that's
noted
there
and
I.
Guess
that's
it.
I
If
people
have
questions,
we
can
talk
about
that
now
or
if
you
want,
you
can
take
a
look
at
the
draft
on
the
on
the
the
actual
draft
and
comment
on
the
mailing
list.
Send
us
feedback.
L
Just
one
thing
that
I
just
now
sort
of
started
thinking
about
that
there
are
so-called
this
EMC
privacy,
extensors
I
think
this
White
Band
Broadband
Forum
has
specified
it.
For
example,
do
these
things
are
interoperate
with
privacy?
I,
don't
know
if
you
know
the
details
of
it,
but
is
there
anything
that
works.
L
But
does
this
bring
anything
new
related
to
that.
I
I
You
perhaps
send
some
link
to
materials,
because
I
mean
I'm,
obviously
aware
of
the
sure,
of
course,
identity,
privacy,
things
within
3gpp
networks,
with
this
Broadband
Forum
thing,
I
am
not.
L
I
B
Because
if
not
I
think
we
should
do
a
working
group
last
call
and
get
whatever
comments.
People
have
I
think
that
the
MZ
privacy
question
might
be
interesting
in
that
the
two
things
are
probably
independent
right,
but
we
might
want
to
just
clarify
that,
whatever
the
properties
for
MZ
privacy,
this
doesn't
change
those
necessarily
or
maybe
it
does
I,
but
I,
don't
think
it
would.
I
Yeah
it
it
it
shouldn't,
like
I,
mean
I,
as
maybe
I
should
make
any
statements
before
looking
at
the
thing
that
we're
comparing
to.
But
but
you
know,
this
is
independent
of
you
know,
whatever
3gpp
is
doing
in
terms
of
similar
arrangements,
and
it
would
be
funny
if
it
was
it
had
an
impact,
but
we
we
can
take
a
look
at
that.
You
know
real
soon
and
I
mean
it
also
can
be
a
thing
that
we
can
do
in
parallel
with
working
with
last.
B
Call
yeah,
yeah
I
think
that
we
should
do
that
so,
like
yeah,
we'll
chairs
will
get
to
I
thought.
I
had
already
queued
something
up,
or
maybe
I
didn't
forgot
about
it
anyway.
We'll
get
that
out.
Thank
you.
L
B
B
B
B
B
H
Behind
the
settings,
the
PowerPoint
as
a
crutch,
which
is
probably
good
practice,
but
public
speaking
so
good
afternoon-
everyone,
my
name-
is
Josh
I'm
here
to
talk
about,
eat
dye,
which
I'll
expand
that
acronym
it's
deep
provisioning
of
identity.
H
So
in
a
way
it's
actually
quite
related
to
Alan's
talk,
but
whereas
Ellen
I
think
will
sort
of
focusing
on
the
provisioning
of
you
know:
secure
configuration
to
supplicants,
I'm
kind
of
more
interested
in
the
inverse
problem,
which
is
how
do
we
de-provision
configuration
from
a
supplicant
and
that
there
are
generally
speaking,
two
ways
in
which
subsequent
configuration
is
managed
on
devices.
You
will
be
well
aware
of
them.
H
You've
got
a
device
management
systems,
so
things
like
YouTube,
which
is
an
Enterprise
settings
to
push
configuration
out
to
large
volumes
of
Enterprise
devices,
and
then
you've
got
manual
Administration
so
giving
you
know
the
end
user,
some
documentation
some
credentials,
and
then
you
know
hoping
that
the
end
user
will
will
manage
to
configure
their
devices
excellent
in
a
way.
That's
secure
and
gets
them
on
the
network.
And-
and
you
know,
we've
spoke
during
Allen's
presentation
about
how
that
is
quite
challenging.
H
Getting
getting
people
on
the
network
with
with
configuration,
but
it's
work
and
is
secure,
but
there
is
also
there
are
issues
associated
with
deep
provisioning
as
well
and
and
my
goal
is:
this
presentation
are
really
quite
straightforward,
so
the
first
is
just
I
just
want
to
raise
the
profile
of
the
problem,
because
it's
not
a
problem
that
we
tend
to
focus
on
very
much.
We
focus
much
more
on
the
provisioning
of
configuration
and
not
the
actual
D
provision.
H
Configuration
I'd
like
to
propose
a
straw
man
as
to
how
we
might
go
about
doing
this
and
get
your
feedback.
I
haven't
written
up
a
drafts,
but
if
there
is
sort
of
interest
in
a
solution
in
the
space
and
I'm
I'm
kind
of
happy
to
do
that
so
next
slide.
Please.
H
So
I've
covered
off
the
first
few
points.
There
second
bullet
point:
if
configuration
is
managed
manually,
so
a
user
with
their
own
device
that
isn't
managed
by
some
Enterprise
device
management
system.
That
configuration
will
almost
certainly
persist
until
the
device
is
replaced.
Users
very,
very
rarely
ever
remove
supplicant.
You
know
a
network
profile
from
their
supplement
configuration
you
can
guarantee
that,
once
the
configuration
is
in
for
a
network,
it
will
be
there
until
the
device
is
recycled,
and
this
this
leads
to
some
issues.
H
So
I
work
in
the
interim
space
and
if
you
look
at
sort
of
a
university
in
a
metropolitan
area
like
London,
you'll,
typically
find
that
about
25
to
30
percent
of
attempted
associations
are
devices
with
invalid
credentials,
which
is
to
say,
is
typically
someone
who's
graduated
from
from
a
university
somewhere.
H
Walking
along
the
street
in
London
sees
the
edge
of
my
Society
bang
attempts
to
authenticate
and
fails,
and
that's
a
pretty
high
volume
of
authentication
attempts
at
least
some
problems.
So
the
first
is
that
it's
it's
wasteful
CPU
battery,
but
in
particular
radio
spectrum.
Radio
spectrum
is
a
scarce
resource
and
having
a
lot
of
devices
in
a
small
area.
Attempting
repeatedly
and
failing
to
connect
to
the
network
choose
up
that
resource.
H
It
distorts
utilization
statistics,
so
we
have
Eduardo
musers.
You
know
campuses
universities,
colleges
so
forth,
who
see
that
their
statistics
are
really
distorted
by
the
fact
that
they
have
a
lot
of
people
just.
H
Walking
through
that
campus
because
they're
a
metropolitan
area
or
something
like
that
and
and
they
see
a
lot
of
Rejects-
and
they
don't
understand
why-
why
are
all
these
users
failing?
Why
is
my
wireless
network?
Look
so
rubbish?
It's
not
the
wireless
networks,
it's
rubbish!
It's
just
that
you've
got
a
whole
bunch
of
users
who
are
attempting
to
authenticate
when
they're
not
authorized
to
and
finally
includes
logging
and
Reporting,
which
makes
things
like
troubleshooting
so
forth
complicated.
H
H
So
we
some
design
requirements.
We
want
to
minimize
the
impacts
on
the
epactors,
so
you
know
the
the
supplicant
and
the
radius
server
the
server
I
think
it's.
You
know
it's
reasonable
to
assume
that
there's
going
to
be
some
changes
to
these
these
actors,
but
we
want
to
minimize
that
second
bullet.
We
want
this
solution
to
be
compatible
with
deploys
infrastructure.
Okay,
so
there
is
an
awful
lot
of
you
know:
access
points,
controllers
and
so
forth
that
are
out
there
in
the
wild.
H
We
want
a
solution
that
that
works
with
those
with
those
systems
without
having
to
upgrade
them.
H
The
third,
which
is
sort
of
the
kind
of
an
interesting
one,
was
that
we
wanted
a
mechanism
that
is
independent
of
the
equal
authentication
method.
Very
often,
you
know,
there's
you
see
sort
of
solutions
around
this
space
and
they
typically
depend
on
tunneling
things
through
the
equal
authentication
method.
So
with
ttls
you
can
Define
tlvs
to
push.
You
know.
Vendor-Specific
information
through
you
can
do
something
very
similar
with
Peep
and
with
petite,
but
those
are
defined
for
each
authentication
method
and
they're,
not
General
across
across
methods
and
I.
H
Solution
that
that
is
general
purpose
so
that
we
don't
have
to
extend,
extend
authentication
methods
and,
finally,
obviously
it
has
to
be
secure
because
you
know
the
whole
purpose
of
this
mechanism
is
to
kick
people
off
the
network.
We
want
to
make
sure
that
only
the
right
people
are
doing
the
kicking
and
not
unauthorized
actors.
H
So
that's
the
problem
that
I've
I've
kind
of
hopefully
explained
and
I
hope
that
everyone
can
generally
see
that
there's
a
problem
to
be
solved.
H
Given
those
requirements,
I
did
a
bit
of
thinking
and
come
up
with
a
kind
of
proposed
solution.
This
is
very
much
offered
in
the
sense
of
starting
a
conversation.
Hopefully
anyone
who
sort
of
sees
a
a
giant,
gaping
hole
will
be
rewarded
with
a
pint
of
beer,
and
so
let's
try
and
try
and
get
some
incentive
to
get
people
thinking
about
this.
H
So
is
effectively
a
mechanism
that
builds
on
the
notification
request
and
that's
that's
defined
by
notification,
that
the
notification
request
is
not
something
that's
that's
widely
used
in
Eep.
H
It
has
some
sort
of
it
has
sort
of
one
property
that
I
find
quite
curious,
which
is
discussed
in
support
for
sequences,
which
is
that
it's,
the
only
Eep
type
that
you
can
use
once
an
authentication
method
has
been
started
so
typically
speaking
with
Eep,
once
neapetype
has
been
negotiated.
That
has
to
continue
until
a
conclusion
whether
it's
a
failure
or
a
success,
and
you
can't
sort
of
start
up
another
week
time
halfway
through
the
discussion
through
the
conversation
and
the
exception
to
that
is,
is
eat.
H
Notification
is
the
notification
type
where
the
Eep
server
can
send,
or
rather
the
authenticator
can
send
a
notification
request
at
any
point,
during
an
authentic
during
the
execution
of
an
authentication
method
and
providing
that
there
isn't
an
outstanding
request
for
the
typing
question.
H
So
what
each
guy
does
is
basically
sends
a
notification
request
to
the
supplicants
and
during
this
process,
and
we
do
we
do
it
at
a
very
specific
stage
in
the
process,
which
is
after
the
derivation
of
the
eat
keys.
But
before
the
Eep
success
has
been
transmitted
so.
D
H
H
All
we're
doing
is
using
this
field
to
send
some
information
and
the
the
data
fields
that
I'm
suggesting
is
a
version
which
just
sort
of
indicates
the
version
of
ebi
that
we're
dealing
with
a
message,
which
is
a
human,
readable
message
that
can
be
defined
by
the
operator
of
the
the
radio
server.
So
something
like
your
access
to
this
network
will
expire
on
an
expiration
date
field,
which
is
a
date
value
and
that
it
can
be
passed
by
both
machine
and
human
and
then
a
message
authenticator.
H
So
the
authenticator
is
a
value
that
allows
the
supplicant
to
authenticate
the
the
message
that's
been
sent
by
the
Eep
server.
So
it's
a
very
simple
structure.
H
M
H
H
So
this
is
the
operation
Step
One,
the
operator
of
the
Eep
server
configures,
an
expiration
policy
for
their
users.
They
might
have
different
policies
for
different
users,
so
you
know
a
student
could
have
an
expiration
date
set
for
their.
You
know
forecast
date
of
graduation,
whereas
a
member
of
Staff
might
be
sort
of
open-enders,
more
open-ended
or
other
before
connecting
to
the
network.
The
supplicant
checks
in
a
cache,
a
local
cache
for
expiration
data
associated
with
the
network
that
it's
going
to
attempt
to
connect
to.
H
If
the
network
configuration
has
expired
because
it
has
some,
it
has
a
date
cached.
It
doesn't
attempt
to
connect
and
disables
that
profile
if
there
is
no
expiration
data
or
if
it
has
not
yet
explored
the
subsequent
and
each
server
engage
in
any
authentication.
As
usual,
when
the
EPS
have
been
derived
in
the
usual
manner.
The
Eep
server
sends
a
notification
request
to
the
supplicant
containing
the
eat
dye
data,
and
this
obviously
is
protected
with
your
message.
Authenticator,
which
is
you
know,
derived
somehow
hand-wathing
from
the
eat.
H
Key
and
the
subsequent
then
validates
the
message
caches:
the
expiration
date,
that's
associated
with
that
Network
and
returns
a
notification
response
in
the
in
the
way
that's
required
by
Eep,
and
then
the
authentication
concludes
with
the
Eep
success
as
usual.
So
that's!
That's
it.
It's
pretty
simple!.
H
Would
have
to
be
a
neat
success
because
for
the
eat
delay
data
to
be
sent,
it
would
have
to
be
selling
or
protected
with
the
authentication,
the
authenticator
field,
which
comes
from
the
key
and
EQ,
and
it
gets
generated
if
there's
been
successful
conclusion
to
the
Authentication,
so
that
that's
that
is
one
of
the
quotes
to
this
is
that
it
only
operates.
If
authentication
is
successful,.
E
Could
also
go
on
to
the
end.
I
can't
wait.
I
know
it
goes
okay,
so
interesting,
because
we
did
look
at
the
notification
part
of
the
state
machine
like
10
years
ago,
because
we
also
wanted
to
send
things
from
radios
over
the
channel
user
visible
to
the
end
user.
E
E
My
follow-up
question
would
then
be:
is
it
foreseen
that
you
can
update
the
termination
date
of
the
account?
Because
sometimes
you
think
the
account
expires,
but
then
the
user
has
to
go
for
another
year
because
he
failed
in
some
some
exams.
E
Okay
and
then
the
final
comment,
which
may
be
a
bit
mean
but
I,
think
the
best
way
to
Signal
such
an
expiration
date
is
probably
when
you
provision
the
data
so
for
those
few
operating
systems
that
have
proper
configuration
files,
you
would
also
be
say
able
to
say
this.
Configuration
expires
at
I.
Think
Apple
has
one
of
those
in
their
file,
and
this
old
expired
draft.
I
had
also
foresaw
that,
but
in
all
honesty,
these
have
troubles
being
updated
with
a
new
date.
H
D
Please
yes
thanks!
So
just
15
minutes
ago,
I
learned
said
and
complained
that
he
tried
to
connect
with
Wi-Fi
and
nothing
in
response.
So
have
you
ever
thought
that
that
can
be
a
said
that
just
for
the
success,
so
the
same
notification
message
can
be
sent
theoretical
I
guess
for
the
failure,
which
would
actually
be
useful
like
say,
like
certificate,
is
not
trusted
or
something
the.
D
Yeah
understand,
but
still
that
you
cannot
know.
D
L
Well,
yes,
just
quick
note:
you
mentioned
that
the
profile
lifetime
is
the
device
lifetime.
I
just
checked
my
phone
and
I
have
profiles.
There
are
more
than
10
year
old,
so
the
tools
that
one
can
use
to
when
they
get
a
new
phone.
They
helpfully
bring
over
all
the
all
profiles.
So
the
problem
properly
just
gets
worse
over
time.
H
So
five
issues
that
I'd
noticed
for
discussion
Maybe
not
immediately
because
I'm
conscious
of
time
so
issue
number
one,
the
epoxy
talks
of
the
authenticator
and
sending
the
notification
requests
rather
than
the
server
I
think
this
is
probably
an
oversight,
and
what
is
meant
is
the
Eep
server
I'm,
not
sure
why
you'd
want
to
reconstrain
that
to
the
Authenticator,
but
someone
in
the
room
might
know
be
better
than
I.
B
I
think
the
as
I
think
somebody
mentioned.
Not
a
lot
of
thought
has
been
given
into
given
into
the
use
of
notification
so
like
at
at
that
point.
You
know
the
separation
between
authenticator
and
server
was
not
so
well
defined
and
as
it
is
now
and
the
state
machines
are
not
so
well
defined,
and
so
you
know
you're
you
this
may
be
treading
I,
don't
know
if
you've
done
any
experimentation
with
it,
but
you
may
be
dreading
into
Uncharted
undefined
behaviors.
K
H
H
Three
is
really
the
whole
state
machine
problem
and
this
is
kind
of
an
application
of
feature
Veep.
That
is
not
widely
used,
and
so
it's
unlikely
you
know
to
work
out
the
box
with
you
know,
substance
and
each
servers
that
exists
today.
H
Tweaks
that
are
needed
to
get
this
working
again,
I'd
be
very
interested
in
implementers
views
on
that
Issue
Number
Four,
which
we've
touched
on,
which
is
the
eat
dye,
requires
there
to
have
been
a
successful
authentication
in
the
past
in
order
to
get
that
date,
cached
and
set.
H
Does
this
limit
the
utility
I
think
not
personally
I?
Think
if,
if
you've
had
one
authentication,
that's
that's
probably
sufficient,
but
again
you
may
have
a
different
view
on
that
and
then
issue
number
five
is
the
the
right
architectural
layer
at
which
to
address
this
problem,
which
is
sort
of
I,
think
Stefan's
Point,
which
was
that
you
know
we.
We
have
Enterprise
device
management
tools
for
managing
this.
H
H
B
All
right,
yeah,
I
guess
one
concern
I
do
have
is
like
with
the
state
machine
and
that,
like
you're
gonna
say
if
you
send
a
success,
the
authenticator
is
going
to
think.
Oh,
you
know
now
maybe
you're
going
to
get
network
access
and
if
you
try
to
send
key
material
in
the
correct
thing,
then
you're
going
to
give
network
access.
B
Maybe
when
you
don't
intend
to-
or
maybe
you
do,
I
don't
know
and
there's
probably
some
key
derivation
things
we
need
to
work
out
like
whether
we
use
emsk
and
if
we
use
emsk,
is
that
limiting
because
people-
maybe
that's
not
what
implemented
things
like
that.
But
anyway,
John.
J
In
in
regard
of
question,
four
I
think
it
would
be
definitely
useful
to
have
this
mechanism,
but
maybe
that's
more
than
the
the
implementation
side
to
have
the
the
profile
disabled
and
not
deleted,
because
I
can
imagine
some
use
cases
where,
maybe
if
you,
if
you
set
the
the
time
frame
to
small
that
people,
will
go
on
vacation
and
then
come
back
and
see.
J
Oh,
my
Eddie
ROM
is
not
working,
and
if
you
have
the
possibility
to
then
just
click
try
again
and
then
you
try
the
the
authentication
again
and
then
it
works
because
it
still
has
the
the
configuration
there,
but
it's
just
not
configured
to
connect
automatically
that
that
would
be
good.
J
J
I
would
be
very
glad
to
see
this
working
because
I
I
see
a
lot
of
authentication
processes
and
yeah
getting
rejected,
mostly
because
the
people
never
bothered
to
disable
their
at
your
own
configuration.
And
if
we
can
do
something
about
that,
open
doors.
I
will
happily
contribute
there,
but
I'm
not
exactly
sure.
If
the.
If
the
supplicant
supplicants
will
actually
implement
it,
foreign.
B
Overlap
between
this
and
we
talked
at
the
beginning
of
the
meeting
there
was,
you
know,
configuration
related.
B
This
is
in
a
sense,
configuration
information
and
maybe
there's
a
different.
Maybe
we
can
use
a
channel
within
the
eve
method.
The
tunnel
method
might
might
that
again
is
limiting,
but
that
might
be
a
little
bit
simpler
in
terms
of
the
eve
State
machine
in
that,
like
all
of
that
happens
within
the
tunnel
method,
you
don't
have
to
worry
about
what
the
authenticator
is
going
to
do,
and
you
know
all
that
kind
of
stuff.
B
There
might
be
something
to
to
also
think
about
yeah.
This
is
also
sort
of
a
generic
problem
like
you
could
have
the
same
problem
with
with
just
you
know.
You
know
you're
trying
to
connect
in
your
your
Wi-Fi
you're,
using
WPA
whatever
with
a
pre-share
key,
and
your
key
is
old
and
you're
just
going
to
keep
trying
the
same
thing
and
it's
going
to
fail.
I'll
fail,
I,
don't
know
if
there's
any
defined
behavior
in
those
cases,
but
it
seems
like
it
could
end
up
in
the
same
problem.
B
So
maybe
there's
something
at
the
Wi-Fi.
You
know
level.
You
would
do,
and
maybe
that
could
be
protected
it
in
some
way,
but
so
I
think
there
could
be
a
couple
different
options
depending
on
different
things,
but
it
does
seem
like
this
is,
is
a
problem
we
have
Matthew,
you
should
Vadim,
you
should
sign
into
the
thing,
so
you
could
join
the
queue,
but
let's
see.
M
Matthew
Newton
free
writers,
obviously
yeah
I,
totally
agree.
The
whole
thing
from
an
edger
and
background
of
telling
users
that
they
shouldn't
be
on
definitely
sounds
like
a
good
thing
to
do
in
terms
of
the
message:
I,
don't
know
where
there's
a
I'm
coming
in
coldons,
where
there's
something
there
are
other
cases
when
you
want
to
send
a
message
back
as
I
think
I,
don't
know
somebody
said
earlier
of
yeah
and
something
has
failed
and
devices
currently
just
don't
show
anything
and
whether
that
should
be
separate
to
this.
M
Because
do
you
want
to
set
an
expiry
date
without
I
mean
if,
if
a
device
gets
this
notification
every
single
time
it
connects?
Is
it
gonna,
then
pop
up
a
message
on
the
screen
straight
away
every
single
time
it
connects.
M
Do
you
want
to
disconnect
the
message
and
use
that,
for
other
useful
things
from
the
setting
the
expiry
date
and
then
also
I
can
see
something
where
something
goes
wrong
on
the
server
and
you
set
a
an
expiry
date?
It's
incorrect.
Possibly
do
you
want
to
say
okay,
actually,
I
didn't
I
didn't
mean
to
say
that
at
all
remove
it.
That's
probably
a
certain
thing.
E
M
M
D
So
probably
I
I
will
definitely
take
a
look
on
that
later.
Maybe
if
I
not
understood
correctly
so
correct
me
with
this,
and
but
do
you
plan
to
different
differentiate
between
the
machinos
and
the
users,
especially
that
should
draw
us
actually
by
asking
with
we
have
the
hip
chaining
right
for
the
fast
and
tip
and
do
does
it
really
make
sense
or
it
doesn't
make
sense
at
all
I
just
don't
understand.
D
H
H
It
could
well
be
yeah
good
point,
yeah.
B
That
profile
like
this
profile
is
provisioned
by
somebody
right
and
it
could
be
the
same
people
that
are
provisioning,
both
the
machine
and
the
user,
but
it
could
be
different
and
I
think
if
we
go
down
the
path
of
there
being
some
kind
of
configuration
information,
we
have
to
understand
who
owns
that
configuration
and
owns
the
expiry,
and
all
of
that,
so
it's
a
little
a
little
bit
tricky
but
yeah,
it's
more
more
thought
needs
to
be,
but
you
know
I
think
we
have
a
good
start
to
at.
B
F
B
I
think
we
can
is
it
in
slide.
J
Okay,
yeah
for
for
those
present
at
the
ATF
113
in
Vienna-
maybe
you
you
remember
me:
rushing
through
these
slides
in
like
under
one
minute,
hopefully
I
can
I
can
go
through
these
slides
this
time
with
a
little
bit
more
time
so
for
the
IDF
in
Vienna,
I
submitted
two
drafts,
one.
The
observations,
that's
now
already
expired
and
I.
J
Don't
really
have
any
intention
to
to
follow
up
on
that
and
it
was
never
intended
to
be
an
RFC,
but
ibnoop
I've
actually
worked
on
a
little
bit
more
next
slide.
So
for
a
master's
project.
At
my
University
I,
looked
into
ibnoop
and
I
have
seen
a
few
things
that
I
yeah
I
was
not
sure
exactly
why
the
the
protocol
was
specified
like
that.
J
The
first
thing
that
I
noticed
is
we
use
Json
as
pay
load
and,
of
course,
when
you're
working
with
iot
devices-
and
you
hear
Json
yeah.
Well,
it's
not
really
well
suited
for
for
iot
devices.
We
have
strings
as
map
keys,
so
we
get
quite
long
messages.
J
We
have
some
canonicalization
issues
if
we
calculate
the
hmac
over
these
messages
and
we
also
use
the
message
contents
to
form
an
adjacent
array
that
is
then
used
for
the
hmac
calculation.
So
there
are
some
some
concerns
there.
Next
slide,
I
will
skip
over
the
the
surveying
for
p
info.
J
We
have
a
quite
High
number
of
messages
exchanged,
for
example,
the
the
first
message
from
the
server
to
the
client
actually
does
not
contain
any
information
except
for
hi.
This
is
an
initial
message
and
the
peer
then
transmit
transmits
its
state
and
its
peer
ID.
J
So
I
think
that
this
could
be
reduced
by
at
least
one
round
trip
if
the
transmission
of
the
PS
date,
for
example,
is
done
implicitly
where
the
choose
of
reply
messages
by
the
pair
and
one
editorial
knit
I
found
is
that
the
noob
specification
never
or
the
the
noob
RFC.
Never
X
implicitly
defines
that
this
is
version
one.
There
are
only
example:
values
given
I'm,
not
exactly
sure
this
could
be
fixed
with
a
narrata,
so
I'm
still
new
to
the
process.
Okay,
next
slide.
J
So
what
I
did
after
looking
at
this
specification
is
saying.
Well,
we
can
try
to
to
use
the
same
design
principle,
because
I
I
found
the
the
design
principle
quite
interesting
to
use
an
out-of-band
message
to
authenticate
the
The
inbend
Exchange
and
I've
written
a
specification
called
utter
users
as
the
trust
establishment.
It's
basically
the
same
design,
but
instead
of
Json
I
use
sibo
as
a
message
encoding,
cbos
sequence
and
sibo
maps
and
the
Mac
calculation
is
done
over
the
whole
message
instead
of
just
parts
of
the
message
combined.
J
So
this
also
adds
the
possibility
to
extend
the
protocol
without
the
need
for
all
devices
to
to
understand
each
part
of
the
protocol,
because
you
can
just
take
the
whole
message
put
it
in
your
Mac
calculation
and
you
don't
need
to
understand
every
bit
next
slide
yeah.
So
the
the
current
state
I
have
presented
it
and
at
the
113
I
haven't
got
any
feedback.
I
have
worked
on
it
since
so
the
the
zero
one
version
is
now
published.
J
It
contains
a
more
or
less
complete
specification
of
the
base
protocol,
there's
still
a
number
of
to-do's.
Of
course,
in
the
draft.
J
This
was
part
of
my
Master's
project
yeah,
so
I
have
an
implementation
for
this,
with
the
initial
and
completion
exchange,
so
the
first
onboarding
mechanism
for
the
device,
radio,
with
ESP
IDF
on
the
client
side
and
my
own
Ruby
server
based
server
on
the
server
side
next
slide.
So
my
question
to
this
working
group
would
be:
is
this
useful
work?
I
haven't
really
found
any
documentation
of
noob
being
used
anywhere?
J
So
the
first
question
or
the
most
important
question
is:
is
this
possible
or
useful
work
item
for
emu
or
should
I
just
stop
working
on
it
because
nobody
uses
ibnoop
anyway,
so
iputer
won't
solve
a
reasonable
problem
and
of
course,
then
the
following
questions:
if,
if
it
is,
is
it
okay
to
to
Define
new
protocol
or
should
I
try
to
Define
it
as
a
new
version
2
with
all
the
problems
that
come
with
it.
B
I
I,
don't
know
of
any.
You
know
large
deployments
that
use
epnew,
so
I,
don't
know
I,
don't
think
there's
and
it's
fairly
new
as
far
as
a
draft
published
so
I
I
don't
know,
but
I
haven't
heard
of
many
plans
to
use
it
either
so
yeah
I
I,
don't
know
that
it's
necessarily
a
fruitful
path
to
go
down,
but
I
think
certainly
some
of
the
learnings
I
know
we
did
have
some
discussion
on
Json
versus
other
formats
and
I
think
we
went
with.
B
We
stayed
with
Json
because
that
was
what
was
already
defined
and
there
wasn't
desire
within
the
working
group
to
go,
make
that
change
at
that
time,
but
yeah
so
I
don't
know
if
anybody
else
has
any
information
on
deployments
of
each
noob.
J
I
mean
it
is,
it
is
a
very,
very
specific
protocol.
It
was
chartered
to
to
have
one
of
these
method
methods
defined
in
emu.
I
have
thought
of
some
applications
where
you
can
actually
use
that
to
to
gain
access,
but
yeah.
If
there's
no
no
interest
in
the
working
group,
then
I'll
just
keep
it.
As
my
contribution
to
my
Master's
project
and
I
will
not
pursue
this
any
further.
B
B
B
All
right
well,
thank
you
for
joining
our
Monday
session
enjoy
your
week.
Joe
yeah
Dan,.
F
Were
we
going
to
do
a
bootstrapped
TLS?
We
can
I,
don't
see
a
lot
but
yeah.
B
Owen
Owen,
apparently
can
is
ill
and
could
not
make
it
and
then
Elliot
was
gonna
present
and
then
he
couldn't
make
it.
But
if
you
would
like
to
say
some
things
that
would
be
fine.
F
Yeah
I
mean
I
might
as
well.
We
have
half
an
hour
right,
yeah.
B
F
Okay,
yep.
Thank
you
so
yeah.
This
is
a
the
newly
minted
bootstrap
TLS
version.
One
next
slide:
please.
F
And
to
remind
everybody
the
the
goal
here
is
we
wanted
to
reuse
the
bootstrapping
techniques
and
the
bootstrapping
key
formats
that
the
device
provisioning
protocol
uses
and
use
them
to
to
authenticate
a
wired,
a
wired
device.
So
you
know
what
happens?
Is
you
know
you,
you
plug
a
wired
device
into
an
82.1x
Network
and
the
first
thing
it
does
is
say:
what's
your
Eep
identity
and
if
the
device
just
is
not
provisioned,
then
it's
the
classic
Catch-22.
F
So
what
we
wanted
to
do
is
use
the
DPP
bootstrapping
key
to
form
a
psk
and
then
inject
it
using
9258
into
into
TLS
and
then
do
normal
well,
I
guess
not
normal.
It's
8773,
cert,
based
authentication
that
also
uses
an
external
psk,
namely
the
one
that
we
just
imported
and
then
the
client
authenticates
using
his
raw
public
key
to
prove
possession
of
the
private
analog
to
his
public
bootstrapping
key
next
slide.
Please.
F
So
we
we
did
have
some
feedback
on
the
on
the
mailing
list
and
we
did
make
an
o1
version
of
this.
This
document
we
we
did
reorganize
some
of
the
stuff
to
hopefully
make
it
more
readable.
So
if,
if
people
would
comment
on
that,
it
would
be
helpful.
I
got
a
email
from
Amanda
and
Ayanna
regarding
the
identity
that
we're
we're,
adding
to
dpp.orpa
and
I,
haven't
gotten
back
to
her
about
that,
but
we
will
definitely
do
that.
So
next
slide
please.
F
So
this
is
what
it
looks
like.
The
the
the
Bold
text
is
the
stuff
that
we're
adding
for
DPP
and
the
the
non-bold
text
is
just
your
the
Plain
Jane
TLS
1.3
handshaking.
F
So
basically,
the
the
public
key
is
going
to
get
hkdf'd
into
a
into
a
psk
and
then
using
9258
it's
going
to
get
injected
into
the
into
the
TLs
handshake.
We
we
drive
an
imported
identity
for
that
that
key
and
that
gets
gets
included
in
the
in
the
client,
hello.
The
server
then
can
look,
this
up,
find,
find
the
psk
and
then
and
then
continue
with
the
rest
of
the
handshaking,
which
again
is
a
certain
with
external
psk,
and
then
the
clients
can
authenticate
with
with
his
raw
public
key.
F
So
the
reason
we're
going
to
this
trouble,
then
is,
is
this:
we
want
to
use,
use
it
with
teep.
So
what
happens?
Is
you've
got
this
wired
device?
That
has
you
know
a
Lim,
no
or
a
very
poor
user
interface,
and
it
has
no
no
provisioning
to
get
on
the
network,
so
you're
gonna,
it's
you
plug
it
into
the
network
and
the
the
authenticator
says.
F
What's
your
what's
your
Eep
identity
and
the
response
is
TLS
poke
at
dpp.arpa,
which
indicates
to
the
authenticator
that
he
should
start
keep
and
do
this
new
type
of
TLS
with
a
with
a
bootstrapping
key,
so
that
that's
going
to
get
get
authenticated
and
then
we
use
the
existing
teep
tlvs
to
enroll
into
the
into
a
CA
passing
a
pkc
S10
and
getting
back
a
pkc,
a
seven
bag
asserts
and
then
the
the
client
can
can
provision
those
the
that
that
certificate
and
use
it
for
for
any
subsequent
connection
that
it
has
to
use
what
it
has
to
do
so
next
slide.
F
Please
Elliot
tells
me
that
he's
found
some
students
that
are
going
to
be
implementing
this,
which
is
good
I'm,
going
to
try
and
implement.
This
I
noticed
that
Rob
Rob
public
Keys
when
in
TLS
1.3
is
a
is
a
feature,
that's
being
added
to
open
openssl
and
when
that's
done,
I
think
it'll
be
a
lot
easier
to
to
to
to
roll
this
out.
But
but
again,
these
are
we're
not
doing
any
any
funky
changes
to
the
TLs
handshake.
F
B
Yeah,
if
we
can
have
a
show
of
hands
of
people,
have
read
the
draft
or
no,
so
we
have
a
couple
people
in
the
room
and
I
don't
know
if
anybody
was
on
the
chat,
so
it
would
be
good.
This
is
a
working
group
item
It's
relatively
newly
adopted,
but
it
would
be
great
if
we
had
some
additional
review
that
in
the
working
group.
D
A
B
Should
have
some
more
discussion
on
the
list
on
this
it'd
be
great
to
get
some
reviews
coming
in,
so
that
we
can
start
figuring
out
how
we
move
this
forward,
all
right
now,
I
think
now
we
may
really
be
done
this
time.
So
all
right!
Thank
you!
Everybody
and
we'll
see
you
next
time.
M
B
Try
to
update
it
or
something
I,
don't
know
it's.
Maybe
it's
something
to
talk
to
me
that
tell
folks
about.