►
From YouTube: IETF114 EMU 20220727 1900
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
this
is
email
working
group
at
ietf,
114.
C
A
D
A
Other
things
is
in
the
room.
Please
wear
a
mask,
except
when
speaking
at
the
microphone.
A
A
A
pretty
full
agenda,
but
I
think
we
should
have
time
to
get
through
all
of
it
and
maybe
have
a
little
time
for
some
discussion
at
the
end.
One
thing
I
would
like
to
do
is
is
recognize
that
mo
hit
stepping
down
as
chair
due
to
additional
responsibilities
from
his
professional
job.
A
A
All
right
does
anybody
have
any
modifications
they'd
like
to
make
to
the
agenda.
A
F
Yeah,
so
not
a
lot
up
from
last
time
go
to
the
next
slide,
so
we
seem
to
be
good
to
go.
The
document
is
okay.
F
I
haven't
heard
of
any
implementation
issues
other
than
implementation
choices,
so
I
don't
want
to
name
names
and
embarrass
people
too
much,
but
one
implementation
has
decided
to
not
support
new
session
ticket
for
ttls
and
peep,
and
presumably
everything
else
and
the
configuration
for
that
does
not
always
work,
and
I
I've
seen
questions
about
this.
F
F
This
will
cause
significant
loads
on
back-end
databases,
especially
in
university
settings.
Where
every
hour
you
have
you
know,
20
000
people,
closing
your
laptops,
walking
across
the
hallway
and
opening
your
laptops
again.
F
F
A
Yeah,
I
think
so
thanks
does
anybody
have
know
of
any
open
issues
in
this
dock?
I
think
it's
probably
something
that
we
can
move
forward.
A
I
don't
know
that
we
need
to
do
another
working
group
class
call
on
it,
because
I
don't
think
that
changes
with
that,
but
we'll
go
back.
D
A
A
C
Now
yard.
E
Okay,
so
this
is
an
update
on
this
forward
secrecy
draft.
E
So
draft
status
has
been
fairly
ready,
in
my
opinion,
for
some
time
module
one
discussing
about
encoding
of
the
graphic
values
we'll
talk
about
that
in
slide.
Four-
and
I
guess
the
authors
at
least
believe
that
there's
an
opportunity
to
deploy
this
and
gain
significant
security
improvements,
particularly
against
some
pervasive
surveillance
activities.
If
you
get
some
of
the
keys,
then
that
that's
really
bad,
but
this
this
this
specification
can
help
there
to
some
extent,
at
least
for
the
newest
person.
E
John
torrent
is
one
of
the
co-authors
in
the
draft,
and
we
improved
the
draft
in
in
in
a
number
of
ways
like
three
and
then
we
went
through
on
our
side
at
least
the
background
with
regards
to
the
current
source
of
encoding,
and
that
that
was
is
indeed
on
slide.
Four
and
my
wish
is
to
start
working
with
last
wall
now
we're
ready
for
that.
E
I
think
almost
regardless
of
you
know
what
what
a
discussion
there
might
be
unless
there's
something
drastic
that
we
haven't
heard
of
before
next
slide,
so
the
other
changes
or
other
topics.
Beyond
this
encoding
issue,
we
attempted
to
further
improve
the
explanation
of
what
does
this
actually
provide
in
terms
of
security
benefits.
We
attempt
to
also
say
that
this
is
that's
important
to
migrate,
the
existing
systems
to
use
the
forward
secrecy
method,
and
we
make
a
recommendation
to
do
this
migration.
E
E
So
in
in
the
last
couple
of
ideas,
we've
had
some
discussion
about
the
public
value
encoding,
and
so
we
went
through
the
discussion.
We
looked
at
the
references.
We
looked
at
some
other
systems
and
some
open
source
cryptographic,
library,
implementations.
E
E
Of
course,
we
could
miss
something,
but
hopefully
you'll
tell
us
we'll
also
observe
that
this
exactly
same
arrangement,
the
same
lengths
and
so
on,
is
used
by
the
3gb
5t
specifications
for
another
purpose,
where
they
use
this
publicly.
This
particular
public
key
technology
and
given
this
background,
we'd
like
to
keep
the
context
and
move
forward,
so
this
is
sort
of
aligned
to
what
is
anyway
done
in
the
phones,
and
that
was
a
strong
reason
for
us
to
keep
keeping
it
as
as
it
is.
E
There
are
other
alternatives
and
they
might
even
be
both
for
some
benefits,
but
also
perhaps
some
downsides,
so
so,
for
instance,
we
could
allow
both
compressed
and
uncompressed
forms
which
is
allowed
by
sec-2,
but
that
would
of
course
introduce
you
know.
Maybe
additional
negotiation
or
issues
with
like
you
have
to
support
both
and
so
forth,
so
maybe
not
actually
worth
it
and
yeah.
So
I
guess
the
the
main
question
here.
If
anybody
objects-
and
I
know
john,
do
you
want
to
add
anything?
Does
that
miss
anything
someone
says
no.
E
Please,
if
you
have
objections
or
other
observations,
or
you
know
whatever
comments,
please
come
to
the
mind.
A
A
C
C
So,
to
remind
everyone,
this
is
intended
to
solve
the
onboarding
catch
22,
which
is
that
you
need
a
credential
to
get
on
the
network,
but
you
need
to
get
on
the
network
to
get
a
credential,
so
how
you
solve
that
has
been
pretty
much
well
well
solved
for
wi-fi
with
the
dpp
protocols.
What
we
want
to
do
is
we
reuse
the
dpv
bootstrapping
mechanism
and
the
ecc
key
pair
format
that
it
proposed
and
use
that
to
onboard
devices
on
the
wired
networks.
C
We're
going
to,
we
want
to
use
hkdf
to
drive
a
pre-shared
key
from
this
bootstrap
key,
which
is
actually
a
public
key,
then
due
to
serve
based
off
with
external
psk
addition
to
tls
and
do
a
raw
public
key
authentication
for
the
client
side,
using
the
bootstrap
and
key
the
nice
thing
about
this.
Is
that
we're
not
proposing
any
extensions
or
changes
which
we
have
been
doing
in
previous
versions?
Next
slide,
please!
C
We
had
been
using
a
draft
from
the
tls
working
group,
extensible
psks,
but
that
doesn't
really
look
like
it's
going
anywhere
and
we
didn't
want
to
pitch
our
wagon
to
something:
that's
not
not
really
moving,
and
we
were
told
that
the
best
way
to
do
this
was
to
use
the
tls
external
psk
importer
draft,
which
is
trying
to
canonicalize
when
you
import
a
psk
much
in
the
same
way
that
there's
exporters
that
you
can
take
secrets
out
of
the
tls
context
secrets
in
so
basically
we
used.
C
We
used
that
specification
to
define
how
we
can
take
this
bootstrapping
key.
We
use
hkdf
to
produce
the
epsk
and
the
psk
id,
and
then
we
construct
the
imported
identity
per
this
spec
to
use
this
epsk
and
epsk
id
and
import
it
into
the
tlst
schedule.
Next
slide.
Please.
C
So
this
is
how
tls
would
look
like
using
dpp
dpv
bootstrapping
keys,
so
the
the
text-
that's
not
bold.
Faced
is
just
your
typical
plain,
jane
tls
exchange
and
the
stuff
that
says
boldface
is
present
if
you're
doing
dpp
bootstrap
so
what's
going
on
is
the
the
client's
saying
we
want
to
do
authentication
using
the
service
kind
of
a
serp,
we're
going
to
add
an
external
psk.
C
The
clients
will
authenticate
with
a
raw
public
key,
and
then
you
define
what
the
pre-shared
key
is
using
again
this
this
importers
construct
the
server
responds
in
kind,
and
then
they
just
do
the
finished
messages
they're
good
to
go
so
again,
the
only
real
change
we
did
between
three
and
four
was
where
the
arrows
show
the
pre-share
key
being
added.
This
is
now
using
the
external,
psk
and
quarter
proposal
next
slide.
Please.
C
So
then,
how
this
fits
into
into
emu
is.
The
proposal
is
to
is
to
use
this
to
authenticate,
so
the
the
device
will
basically
plug
into
a
switch
we'll
get
a
deep
identity
request
and
he
responds
by
saying
tls
proof
of
proof
of
knowledge,
in
which
case
the
server.
G
C
That
he's
going
to
be
doing
this
dpp
authentication
and
then
tls
will
be
authenticated
using
ppp
bootstrapping.
Once
teep
has
been
authenticated,
it
can
proceed
to
the
normal
pkcs107
exchange.
That's
already
part
of
teep,
and
now
the
the
client
has
a
certificate
and
his
subsequent
connection
will
be
using
that
provision
certificate
next
slide.
Please.
C
So,
as
I
said,
this
is
the
fifth
version
of
this
draft.
We
do
have
some
running
code.
That
owen
wrote
I'm
I'm
working
on
trying
to
get
this
to
work
with
open
ssl,
there's
a
new
7250
pr
for
openssl
that
I'm
going
to
try
and
take
advantage
of
once
that
gets
released,
but
we
don't
have.
We
only
have
one
implementation
with
this.
So
far
we
have
gotten
some
good
reviews
from
the
tls
working
group
again
earlier.
C
Proposals
for
this
required
new
tls
extensions
and
required
changes
to
the
tls
key
schedule
which
made
everybody
nervous.
So
when
we
presented
this
at
ietf
110,
we
got
some
very
good
advice
from
people
at
the
tls
working
group
to
use
8773
and
7250.
Instead,
which
was
a
great
recommendation.
So
we
did
that
and
then
we
got
some
more
some
more
review
in
111
and
then
finally,
in
vienna
we
were
told
that
we
should
probably
not
use
the.
C
We
should
probably
use
the
psk
importers
and
not
the
old
field
method
of
of
naming
psks.
So
I
think
we've
got
a
very
good
amount
of
review
again.
This
doesn't
require
any
changes
to
tls.
There's.
No,
no
new
extensions,
there's
no
change
to
the
key
schedule.
This
is
all
using
existing
rfcs
and
a
soon.
C
It's
still
draft,
but
existing
proposals
that
have
gotten
you
know
good
good
vetting,
so.
C
A
Okay,
does
anybody
have
any
questions
or
comments
relating
to
this
draft.
H
H
B
H
G
Hi,
when
you
say
it's
never
used
again,
I
assume
I
assume
you
mean
unless
the
device
is
reset
and
needs
to
be
repaired
to
a
network
again,
or
is
this
literally
once
ever.
D
C
Reset
the
factory
defaults,
then
I
guess
it
could
probably
conceivably
use
its
bootstrapping
key
again,
but
if
this
is
basically
just
a
one
one
time
get
me
on
the
network.
D
Yeah
I
just
wanted
pointing
out
what
jonathan
hamill
already
did,
that
rfc
9258
is
the
external
psk
importer.
It's
published.
C
A
Any
weirdness-
and
I
I
think
this
also
fits
into
the
charter.
We
have
a
charter
item
for
bootstrapping,
keying,
material
or
credentials.
G
A
Now
we
have
ad
hoc.
A
I
D
A
I
So
next
we
can
proceed
to
to
see
a
the
summary
of
everything
that
a
highlight.
D
D
B
I
Which
stands
for
fmldf
helmand
over
cosi,
pro
edward,
provides
a
very
compact
and
lightweight
authenticated.
I
Difficult
monkey
exchange
with
fml
keys,
provides
mutual
authentication
for
secrecy
and
identity
protection,
and,
what's
one
of
the
most
interesting
things
I've
er
about
at
hawk,
I
think
it's
that
it's
a
it's
very
suitable
for
constrained
scenarios,
so
having
any
methods
using
a
ad
hoc
would
provide
a
very
constrained
and
many
a
minimum.
If
method
that
could
be
used
in
constrained
scenarios
in
here,
we
can
see
one
of
the
main
changes
we
highlighted
in
this
version
is
the
use
of
privacy
friendly
request.
I
Identity,
sorry-
and
we
can
see
that
the
main
exchange
would
take
care
of
about
six
messages,
so
it
would
be
these
messages
that
are
also
very
expected
to
be
constrained,
not
very
long
and
after
the
hockey
exchange.
We
would
just
provide
the
success
indication
if
everything
goes
okay,
so
the
next
slide.
Please.
I
This
is
one
of
the
main
highlights
in
this
version,
which
is
the
use
of
the
privacy
friendly
response
identity.
So
we
have
added
a
requirement
to
avoid
a
permanent
identifiers
in
clear
text
in
the
in
the
response
identity,
and
we
added
using
a
ni
recommendation
to
omit
your
surnames
or
similar,
and
here
we
can
see
some
examples.
We
could
just
use
a
real
or
anonymous
realm
or
unencrypted
identity.
I
I
Part.
Okay
and
basically
the
workings-
are
exactly
the
same
as
ftls.
So
I
think
there
should
be
no
issues
on
how
fragmentation
is
is
managed
in
this
case
as
well.
I
Actually,
what
we
are
using
is
the
message
for
which
is
already
present
in
ad
hoc,
although
in
ad
hoc
is
optional
for
e-network,
we
are
stating
that
it
should
be
mandatory
to
use
to
be
compliant
with
the
alternative
success
indication
and
the
next
slide.
Please,
and
basically,
we
also
added
a
different
error
use
cases.
Okay,
for
when
the
error
is
generating
generated
on
each
of
the
messages
from
ad
hoc.
So
the
idea
is
that
anytime,
a
message
is
not
processed
correctly.
I
I
So,
basically,
in
this
version,
I
think
we
address
all
the
issues
that
were
raised
in
the
mailing
list.
We
would
appreciate
any
review
from
from
the
working
group.
We
do
not
expect
any
more
a
lot
of
changes
or
major
changes,
because
ad
hoc
is
already,
we
think
a
very
mature
draft.
Okay-
and
we
would
like
to
raise
the
question
to
the
working
group-
is
that
this
work
is
ready
for,
for
adoption
would
be
adopted
for
by
the
working
group,
and
that
would
be
it.
Thank
you
very
much.
A
I
I'd
like
to
get
a
a
measurement
of
how
many
folks,
in
the
in
the
chat
and
in
the
room,
have
have
read
this
trap,
so
you
could
raise
your
hand
or
indicate
in
the
chat
if
you
read
the
strap
anybody
in
the
room.
One.
A
All
right,
I
think,
we'll
want
to
see
a
little
more
review
and
perhaps
discussion
on
the
on
the
list
of
this
draft.
I
think
we'll
also
have
to
evaluate
it's
not
clear
to
me
if
it's
within
the
charter
as
it
stands,
which
isn't
necessarily
a
problem,
but
we
might
have
to
amend
the
charter
to
to
take
something
like
this
on,
but
if,
if
we
have
support
for
it,
you
know
so
I
think
the
appropriate
thing
to
do
here
would
be
to
have
some
discussion
on
the
list.
A
Make
sure
that
we
have
interest,
and
then
we
will
discuss
kind
of
an
adoption
and
maybe
work
with
with
paul
to
see
if,
if
it's
appropriate,
to
also
amend
the
charter.
F
Okay,
I'll
I'll
talk
for
this
too,
so
we
presented
this
michael.
I
presented
this
in
anima
on
monday.
There
was
a
resounding
so
the
question
for
this
partly
is
whether
this
is
applicable
to
anima,
or
here
there
is
some
overlap
so
for
the
next
slide.
F
What
we're
trying
to
do
here
is
solve
a
brewski
onboarding
problem,
so
we
have
an
unconfigured
device.
It
needs
to
be
onboarded
has
no
credentials
would
like
to
use
unauthenticated
tls
and
join
a
captive
portal
network,
while
5216
allows
for
unauthenticated
epls
it
offers
no
additional
help
and
so
effectively
this
has
been
entirely
unused
and
unusable.
F
So
the
proposal
here
is
to
add
explicit
signaling
via
an
eep.rpra.
This
can't
be
forwarded
or
proxied.
It's
a
signal
from
the
client
device
that
I
want
a
captive
portal
once
it's
on
the
network.
It
has
a
full
network,
full
ipv6,
v4
or
whatever,
and
this
avoids
trying
to
stuff
brewski
into
eep
and
reuses
existing
captive
portal
infrastructures
next
slide.
F
F
The
behavior
of
the
local
network
is
really
a
bit
to
be
defined.
We
can
also
use
to
signal
other
things.
There's
similar
work
being
done
elsewhere.
The
wi-fi
alliance
has
defined
their
own
vendor-specific,
tls
type,
which
does
unauthenticated
epls.
F
This
is
part
of
the
wi-fi
alliance
hotspot
2.0
captive
portals,
so
something
vaguely
resembling
this
is
widely
deployed,
not
defined
in
the
in
the
ietf
defined
in
an
sdo
controlled
by
the
sdo
and
unusable
by
anyone
outside
the
sto.
F
B
F
Sorry,
it's
not
based
on
the
wi-fi
alliance,
but
the
wi-fi
alliance
has
previously
done
something
similar.
I
mean
dan
may
have
comments.
F
B
F
Okay,
yeah,
I
I
don't
know
what
ipr
the
wi-fi
alliance
has
on
this.
Given
that
5216
defines
unauthenticated
tls
and
we're
just
using
this,
I
would
hope
that
there
isn't
much
and
hotspot
2.0
has
all
kinds
of
other
stuff
that
we're
not
doing
here,
but.
C
C
Maybe
one
more
that
one
there
we
go
yeah.
So
that's
kind
of
a
bold
statement
that
is
ca.
Root
is
good
enough
for
web
browsing.
That's
good
enough
for
onboarding!
You
know
cas
are
supposed
to
do
some
due
diligence
before
they
give
out
cert
and
that
due
diligence
that
they
do
for
serving
up
a
web
page.
C
I
know
that
a
lot
of
times
a
client
just
doesn't
care
and
while
cas
do
give
out
search
for
web
browsing,
they
don't
really
give
out
certs
for
onboarding.
So
there's
a
desire
to
you
know
just
do
it,
but
I
think
you
should
it's
kind
of
it's
comment
bait
right.
If
you
make
a
statement
like
that
in
the
draft,
I
think
you're
just
going
to
get
crapped
all
over.
So
I
think
you
you
know
if,
if
you
want
to
use
the.
F
Sure
those
are
all
good
points.
So
part
of
the
reason
for
saying
this
is
there
is
an
additional
bootstrapping
problem
of.
F
If
I'm
going
to
connect
to
an
unauthenticated
network,
it
would
be
nice
to
be
able
to
authenticate
it
right
and
other
in
in
the
absence
of
an
existing
ca,
you
really
have
no
way
of
onboarding
yourself
and
trusting
that
network
without
just
simply
trusting
anyone.
F
F
The
as
best
I
can
tell
the
ca
forum
only
allows
cas
to
issue
certificates
for
use
with
https
that
information
is
buried
all
over
the
place,
so
arguably
using
those
certificates
for
email
or
eep
or
anything
else,
is
a
violation
and
you
know
should
cause
the
certificate
to
be
revoked
and
even
perhaps
the
ca's
authority
to
be
revoked.
F
I
don't
personally
see
it
as
an
issue
here
and
if
it's
forbidden
here,
it
would
be
good
to
understand
why
it's
not
forbidden
or
it
is
for
eat
for
email
for
everything
else,
but
that
that's
a
bit
of
a
larger
discussion
outside
of
this.
So
for
the
purposes
of
this
document,
it
would
be
good
to
be
able
to
authenticate
the
network
you're
connecting
to
even
if
you
don't
authenticate
yourself
and
that's
sort
of
the
smallest
phrasing
I
can
have
that
small
set
of
requirements.
I
guess.
K
Hi
alan
just
had
a
question
about
the
eep.arpa.
K
I
I
I'm
a
little
bit
uncomfortable
with
that,
because
you
know,
if
you
you
could
use
instead,
a
username
with
the
domain
that
you're
looking
to
get
to
I
mean:
are
you
saying
that
you
basically
have
no
idea
what
you're
connecting
to
so
that
you
can't
relate?
You
don't
have
an
expectation
about
whatever
domain
is.
F
So
the
eep.rpa
here
is
the
signal
from
the
client
trying
to
connect
that
it
wants
a
captive
portal
network.
If
you
use
a
normal
domain
and
try
to
connect
there,
then
what
the
server
sees
is:
hey
user
is
trying
to
authenticate,
but
they've
provided
no
client
certificate
with
etls.
F
They
might
be
intending
this
to
work
in
a
captive
portal,
but
that
there's
no
explicit
statement
of
hey.
I
want
a
captive
portal
and
I
have
no
identity
because
I
just
got
bootstrapped
and
I
have
no
idea
what's
going
on
right.
Brewski
is
all
internet
of
things,
so
the
at
8.
arpa
is.
I
have
no
idea
who
I
am.
K
C
Which
raises
another
question:
if
you
don't
know
who
you're
connecting
to
then,
are
you
gonna
sort
of
round
robin
through
every
single
access
point
that
you
see
from
your
scan.
F
Perhaps
right
this
is,
this
is
really
an
issue
independent
of
this
for
brewski,
eight
or
80211u
does
say
that
the
systems
will
will
broadcast
the
domains
they
can
authenticate
for.
So,
if
only
one
broadcasts
eep.rpa,
presumably
that's
the
one
you
connect
to
and
if
multiple
do
yeah
you
don't
really
have
a
lot
of
choice,
even
in
normal
brewski
to
do
anything
other
than
sort
of
round
robin.
J
Yeah,
maybe
I
can
add
something:
brewski
has
some
own
built-in
mechanisms
to
sorry.
My
camera
is
so
to
to
authenticate
the
network
you
are
connecting
to
so
the
mother
voucher
communication
provides
the
device
some
means
of
knowing
whether
it
is
supposed
to
authenticate
to
a
specific
network.
So
I
I
guess
michael
aims
for
using
the
epls,
just
as
a
as
a
transport
mechanism
and
the
the
provisional,
except
of
the
unoff,
just
servo,
authenticated
tls
to
later
on
verify
that
the
device
is
really
onboarding
to
the
network.
J
It's
its
manufacturer
asks
him
to.
F
Yes,
so
the
the
proposal
here
is,
this
is
simply
a
way
to
get
internet
connectivity.
Whatever
happens
after
that
is
elsewhere
defined
elsewhere.
Once
you
have
full
internet
connectivity,
you
can
do
whatever
you
want
to
authenticate
yourself
to
authenticate
the
other
side.
F
Part
of
the
pushback
here
for
me
is
there's
a
lot
of
proposals
to
do
basically
everything
over
eep.
You
know
if
the
only
connection
you
have
between
the
client
and
anything
network
is
beat
based,
there's
a
certain
incentive
just
to
throw
provisioning
on
boarding,
pkcs7
everything
into
eep
and
as
an
implementer.
F
B
Yeah
so
yeah
trying
to
think
about
this.
B
F
I
it
would
be
good
to
have
some
some
kind
of
channel
bindings,
that's
defined
for
other
eat
methods,
but
not
for
not
for
eat
tls,
but
yeah.
That
is
a
good
point
and
in
terms
of
web
pki,
this
is
what
people
do
today
for
eep
right,
you
get
a
certificate
for
radius.example.com
from
a
well-known
ca
and
you
drop
it
on
your
eap
radius
server
and
you
just
use
it
and
depending
on
who
you
talk
to
this,
is
either
perfectly
fine
or
it
will
destroy
the
world.
A
So
it
it
sounds
like
we
have.
You
know
some
questions
here,
raised
kind
of
on
this,
how
you
identify
the
network
and
whether
that's
important
or
not,
for
for
this
use
case,
and
I
think
this
would
be
an
important
thing
to
kind
of
resolve,
or
or
at
least
expand
upon
if
this
is
moving
forward.
Do
you?
What
is
your
intention
here?
Are
you
guys
publishing
a
draft
or.
B
F
Before
the
cut
off
the
current
draft
is
basically
a
line
in
the
sand
of
about
four
paragraphs.
Let's
do
this.
We
will
flush
it
out
and
then
address
all
these
concerns
to
the
best
of
our
abilities,
and
the
question
is
this:
a
lot
of
this
is
really
done
before
the
brewski
work,
so
whether
this
is
done
in
anima
or
e,
I
suspect,
because
it
really
what
what
we're
proposing
here
really
only
involves
changes
to
e
and
any
brewski
work
is
a
second
step.
F
Once
you
have
full
ip
connectivity,
you
just
run
all
the
brewski
protocols
and
they
don't
even
care
how
you
how
you
got
connected,
so
emu
would
likely
be
the
the
best
choice
for
this,
but
the
the
draft
as
it
stands
is
really
there
to
support
brewski.
C
Yeah,
so
one
more
comment:
wouldn't
brewski
take
care
of
the
you
know,
you're
on
the
you're
on
the
wrong
network
problem.
I
mean
if,
if
you
go
to,
if
you
associate
to
this
network,
you
get
on
the
captive
portal
and
you
send
a
voucher,
the
master
is
going
to
go.
Oh
the
voucher
came
through,
you
know,
foo
dot,
com
and
foo
is
not
where
you're
supposed
to
be
so
I'm
going
to
refuse
this
voucher
request,
so
it
since,
since
brewski,
should
solve
that
problem.
C
It
would
seem
to
me
that
your
draft
could
probably
even
be
simpler.
Just
don't
even
worry
about
authenticating
the
tls
connection
for
captive
portal
just
to
a
completely
anonymous
authenticated
exchange,
and
all
you
want
is
ip
connectivity
for
the
for
the
client
and
brewski
should
secure
the
rest
of
it.
For
you
right.
F
A
Okay,
any
if
there
are
no
other
questions,
I
think
you
know
this.
We
should
keep
an
eye
on
this.
I,
since
you
are
reusing
eeptls
in
in
maybe
a
slightly
different
way
here.
I
think
it
would
be
important
for
us
that
this
moves
forward
to
kind
of
understand,
if,
if
that,
has
any
effects
on
other
usages
aside
from
this
one
but
seems
relatively
straightforward,.
A
The
other
topic
I
I
had
here
was
just
to
kind
of
discuss,
you
know
is:
are
there
things
that
we're
getting
through
most
of
our
chartered
items
and
as
we
see
there
are
a
couple
of
new
ones
coming
up,
for
example,
ad
hoc?
Perhaps
this
onboarding
use
case
that
you
know
are,
I
think,
are
not
quite
covered
by
the
current
charter.
A
We've
also
had
some
discussion
in
the
past
on
on
eep,
as
as
in
general.
If
we
wanted
to
to
look
at
the
making
any
sort
of
changes
there,
which
seems-
rather,
you
know
that's
something
that
has
been
brought
up
so
I'd
like
to
understand.
If
and-
and
I
think
also
some
folks
have
brought
some
things
on-
how
to
improve
the
experience
of
eap,
getting
associated
with
networks,
etc.
A
I
think
we're
going
to
have
to
make
a
decision
over
the
next.
You
know,
probably
by
the
next
ietf
on
what
what
sort
of
things
are.
We
are
we
looking
to
bring
into
the
group,
so
I
want
to
understand
if
people
have
any
thoughts
on
that
now
and
if
not,
I
really
would
want
folks
to
be
thinking
about
that.
As
as
we
go
forward.
A
So
if
anybody
has
any
thoughts
or
also
any
other,
since
we
have
a
little
bit
of
time,
chairs
kind
of
last
time,
we
last
couple
times-
we
ran
out
of
time
with
an
hour
and
this
time
of
course,
we
scaled
her
for
longer
and
did
not
have
as
many
presentations.
A
So
if
anybody
has
anything
else
they
want
to
discuss,
you
can
take
some
time
at
the
mic.
A
F
Yeah,
I
still
have
my
other
eep
document,
which
I
think
may
still
be
interesting,
based
on
feedback
from
various
people,
including
elliot
lear.
I
need
to
split
that
into
discovery
versus
configuration.
So,
in
short,
the
proposal
was
put
a
couple
more
oids
into
certificates
and
substantial
amounts
of
deep
configuration
become
easy.
F
There
is
something
similar
in
the
wi-fi
alliance
that
got
pushed
through
based
on
stefan
winter's
work.
The
second
part
of
the
document
is
well-defined
srv
records
for
discovering
all
this.
So
the
theory
for
people
who
haven't
seen
the
document
is,
you
should
be
able
to
say,
I
want
to
connect
to
example.com
and
based
on
a
couple
of
dns,
lookups
and
and
web
server
lookups.
You
can
get
all
your
configuration
for
eep,
including
ca,
server
certificates,
etc.
C
So
is
there
any
desire
to
do
like
another
password-based
authenticated
exchange
and
eep,
so
there's
epwd,
which
is
unfortunately,
informational,
and
it's
also
unfortunate
that
it
does
the
the
hunting
and
pecking
version
of
dragonfly
instead
of
the
the
hashtag
version.
But
since
cfrg
has
produced
cpace
from
their
pake
competition,
it
might,
if
there's
desire,
might
make
sense
to
have
a
password
that
uses
cpas
or
does
any.
If
nobody
cares,
then
there's
no
point
doing
it,
but.
A
H
Yep
john,
yes,
I
think
ellen's
two
draws
here
highlights
the
need
for
more
guidance
and
maybe
requirements
on
how
to
use
certificates
and
certificate
configuration
in
in
eep.
That's
severely
missing,
so
I
think
even
you
should
work
at
that
in
the
future.
Also
strong
interest
from
to
use
more
in
constrained
radio
networks.
I
think
that's
also
something
I
think
emu
should
work
on
and
whether
this
a
shorter
update
or
not
maybe
paul
has
to
answer,
but
I
think
this
should
be
worked
on.
A
Okay,
yeah,
I
think
we'll
we'll
have
to
take
some
of
this
discussion
to
the
list,
but
I
think
you,
you
know
those
are
some
areas
that
I
think
we
have
proposals
in
and
active.
You
know
people
who
want
to
work
on.
D
A
You
know
in
terms
of
ad
hoc
and
and
allen's
draft
and-
and
I
think.
A
You
know
friedrich's
draft
also
was
was
along
a
similar
line,
so
there
may
be
something
there
that
that
we
could
expand
the
chartered
to
kind
of
cover,
but
I
think
we
need
to
have
a
little
more
discussion.
A
A
All
right,
if
nobody
else,
has
any
comments,
I
think
we
can
adjourn
early.
L
Yeah,
sorry,
I
I
didn't
really
manage
to
to
get
my
draft
published
before
this
meeting,
so
I'm
still
working
on
it.
But
I
just
wanted
to
to
get
a
heads
up
that
I
will
publish
a
new
version
of
my
draft
that
I
presented
at
the
113
the
utter
draft,
and
I
would
be
happy
to
receive
any
feedback
also
on
if
there's
any
implementation
of
noob
that
I'm
not
aware
of,
because
I'm
I'm
still
comparing
noob
to
my
new
version.
L
So
I
will
be
sending
to
the
list
because
I
haven't
received
any
feedback
from
since
atf-113.
A
Great
okay,
thank
you,
everybody
and
we'll
see
you
online
and
and
at
the
next
meeting.