►
From YouTube: IETF106-EMU-20191118-1550
Description
EMU meeting session at IETF106
2019/11/18 1550
https://datatracker.ietf.org/meeting/106/proceedings/
A
B
So
I
don't
actually
have
any
slide,
so
I
can
put
about
the
54:48
this
and
then
the
PFS
document
both
of
its
are
working
route
documents.
The
the
base
is
about
to
be
sent,
I,
see
I,
believe
and
there's
been
a
small
update
of
that,
and
that
is
through
Joe's
review
identified
that
there's
a
few
references
that
have
received
in
new
RFC
or
those
revisions
have
been
obsoleted
or
the
RCS
have
been
obsoleted
and
so
I
just
replaced
them
with
new
ones.
So
this
was
for
the
NAI
RFC
for
Ike
v2,
RFC
I.
B
A
B
B
Basically,
based
on
you
know,
better
security
properties,
and
then
there
were
some
somewhat
unclear
references
to
the
the
curve
255
19
and
how
different
numbers
are
generated.
So
there
was
reference
to
can't
remember
that
OC
numbers
of
hand,
but
but
there's
the
the
RFC
that
actually
defines
the
curve
and
then
this
RFC
that
uses
it
for
IP
to
and
actually
deleted
the
ike
v2
reference
entirely
from
that
and
just
refer
to
the
actual
curve
definition
RFC
and
simplified
some
AKA
and
simcard
terminology
and
made
some
other
editorial
changes.
B
So
I
believe
those
are
hopefully
largely
uncontroversial
things
we
did
identify
when
Jen
and
I
were
discussing.
We
did
identify
one
remaining
issue
that
we
didn't
quite
know
how
to
deal
with
so
so.
This
draft
defines
one
algorithm,
the
curve
255
19,
to
do
things
and
what
it
does
is
that
it
carries
this
in
in
one
attribute
that
defines
like
we're
going
to
do
this
particular
extension
and
then
there's
an
attribute,
or
for
this
algorithm,
this
entire
style
of
key
generation.
B
B
If
you
do
this
thing,
then
there's
one
number
that
refers
to
this
particular
style
of
key
generation
and
and
this
particular
algorithm
you
could
also
separate
them,
but
then
it'd
be
more
attributes
and
John
had
also
suggested
that
Mina
maybe
would
be
possible
to
refer
to
some
some
other
registry
of
algorithms.
Of
this,
this
nature
that's
a
possibility
as
well.
B
Although
I
was
looking
at
some
of
the
existing
registers
and
their
numbers
bases
were
kind
of
funny
that
they
were
not
sort
of
neatly
positive,
small,
integral
numbers,
but
it
was
a
cosy
registry
that
was
a
little
bit
funny
in
that
sense
that
he
googles
and
negative
numbers
and
so
on,
but
I
guess.
The
main
question
is:
do
we
need
something
extra
in
terms
of
additional
algorithms
from
day
one?
And
if
so,
is
the
current
structure
of
F
attribute
sufficient
or
not.
C
Then
you
take
a
stab
at
both
of
those.
The
first
is
by
referring
the
question
about
multiple
algorithms.
Over
to
you
know,
two
more
more
knowledgeable
people
who
are
understanding
of
what
the
state
of
standardization
of
the
various
curves
are,
because,
particularly
at
the
nist
level,
because
if
you
have
another
standardized
curve
that
I
know
I
know
they're
coming
along,
but
I
don't
know
where,
where
they,
where
they
land,
it
seems
to
me
having
a
second
having
a
another
go
to
one
is,
is
a
useful
way
to
handle
failover
in
in
case
of
a
crisis.
C
That's
just
you
know
one
view
of
it
at
least.
The
second
point
about
having
multiple
registries
is,
does
having
an
entry
in
the
registry.
What
does
it
imply
in
terms
of
implementation
if
it
implies
nothing
in
terms
of
implementation,
then
overloading
sounds
fine
if
it
implies
something
about
if
it
implies
something
about
an
implementation
in
terms
of
yeah,
you
you
have
to
be
able
to.
Man
have
to
be
able
to
support
it.
Is
it
an
empty
eye?
Is
it
an
option?
Then?
Then
overloading
is
bad.
Yeah.
B
That's
a
good
point
but
I
think
there's
a
separation
between
like
the
requirement
level
that
even
if
we
just
write
things
in
in
our
document,
we'll
have
to
say,
and
even
if
we
have
two
or
three
algorithms,
we
will
have
to
say
that
this
one's
mandatory
and
these
other
ones
are
optional
or
all
of
them
are
around
Natori.
So
that
decision
has
to
happen.
There's
a
separate
thing
about:
do
we
actually
reuse
somebody
else's
number
or
not?.
D
You're,
not
song
so
I
think
it
would
be
good
not
to
to
specify
make
the
document
more
general
and
to
support
a
set
of
algorithm
anon.
It's
correct
to
have
a
state
mandatory
to
implement
tree
DPP.
When
discussing
Sookie
encryption,
three
people
decided
to
standardize
both
curve.
Two
five,
five
one,
nine
and
P
256
there's
also
has
been
in
the
past.
The
general
wish
for
treaty
people
to
have
now
they
did
not
choose
that
for
Sookie,
but
in
the
there's
been
a
wish
to
have
stronger
algorithm,
a
able
to.
D
No
yes
to
support
them
for
as
mousses
I
think
code
to
for
among
nine
as
mandatory
to
implement
everything
else
optional,
but
it
would
be
good
if
the
document
could
just
the
best
thing
would
be
if
we
could
take
the
coastal
register
or
the
TLS
register,
and
just
refer
to
that
and
say
look
here
is
how
to
to
use
any
of
these
that
already
and
rise.
Also
for
this
I,
don't
there's
complications.
How
do
we
transfer
them?
D
B
I,
like
the
idea
that
we
could
have
one
mandatory
to
implement
the
current
one
and
then
add
one
or
two
more
and
sounds
like
you
have
good
candidates
in
mind.
So
so
that's
great
we
can.
We
can
put
that
in
I
can
talk
to
you
offline
and
the
reuse
of
the
register
is
still
troubling
me
a
little
bit
because
it
seems
to
me
that
there's,
when
we
add
algorithm,
is
always
some
specification
needed
that
like
use
it
this
way,
and
it's
not
just
the
numbers
that
that
is
in
the
registry,
so
you
actually
have
to.
B
E
Yeah
I
think
it's
buts,
easier
to
create
your
own
register
and
use
them.
Because
then
then
you
also
you
know
our
control
of
your
registry,
so
you
under
end
up
in
if
you're
using
somebody
else's
register
at
they
say
no,
no,
we
don't
want
to
have
that.
You
know
we
don't
care
about
that
algorithm
and
they
don't
allow
you
to
put
something
in
there
and
then
you
want
to
we
want
to
and
because
they.
B
E
B
Zones
point
was
like
I
mean
I
agree
with
you
that
that
it's
probably
lower
cost
for
us
to
do
our
own
thing,
but
that
Jones
argument
I
think
was
more
like
lifetime
cost
of
this
it's
initially
easier,
but
is
it
cheaper
in
the
long
run?
If
somebody
else
does
does
some
amount
of
work,
there's
that
that's
the
trade-off.
C
Okay,
so
this
is
Elliott
again
short
term
long
term,
okay,
short
term,
clearly
I
think
I'm
coming
down
on
your
side,
long
term.
This
is
something
that
should
be
referred
back
to
the
IAB
because
it
the
there
are
so
many
different
forms
of
encryption
units
in
so
many
different
places,
and
so
many
different
registries,
if
you
go
through
all
the
Registry's,
the
stuff
repeats
itself
again
and
again
and
again
and
again
and
again,
and
so
it
would
be
nice
if
we
had
a
clearer
way
in
the
ietf
to
do
that.
F
D
D
There
so
there's
been
two
updates
since
the
last
IDF,
based
on.
Oh
thanks,
based
on
the
post
working
group,
last
call
comments.
Changes
from
5
to
6
is
based
on
support
in
current
Els
implementation,
especially
OpenSSL.
So
OpenSSL
does
not
support
sending
the
empty
string
as
application
data,
even
if
it's
allowed
by
the
oil
sea.
So
to
fix
this,
the
epls
rod
was
changed
to
sending
a
bomb
byte
of
zeros.
D
D
Another
changed
also
based
on
open
TLS
is
that
up
until
s
does
not
allow
the
server
to
send
early
data
in
the
server
hello
which
is
allowed
according
to
the
RFC,
but
not
implemented
in
open
SSL.
So
we
updated
Roth
to
also
allow
sending
the
commit
message
in
a
separate
message:
that's
and
then
between
0
6,
&,
0
7
was
a
review
by
Jim,
mostly
editorial
and
clarifications.
The
commitment
message
is
now
called
commitment
message
everywhere.
D
There
are
some
privacy
considerations
on
padding
and
listing
that
TLS
103
has
padding
and
recommend
its
use.
Then
there
is
additional
references
to
the
TLS
103
or
C
on
security
considerations
and
clarifications,
and
there
is
a
reference
to
the
now
working
group
adopted,
dropped,
ITF
emu
so
about
certificate
used
an
informal
reference.
It
does
not
depend
on
that
next
slide.
D
Where
did
he
allow
ETLs
103
with
PSK
and,
if
yesterday,
to
answer
how
to
allow
that
so
they're,
starting
by
a
comment
by
two
months
that
EPA
EPS
K
does
not
provide
any
identity
protection
and
does
not
provide
perfect
forward
secrecy
and
he
suggested
to
allow
PSK
in
eap-tls
damn.
There
was
some
discussion
that
EAP
password
provides
perfect
forward
secrecy,
but
a
password
is
not
really
suitable
for
IOT
devices.
D
D
So,
but
if
we
should
do
that-
and
the
question
is,
should
it
be,
should
this
PS
k
use
the
same
method
number
and
should
it
be
defined
in
the
same
document
on
the
first
question?
I
would
say:
yes,
I,
don't
think
it
helped
having
it
the
same
in
different
number.
The
second
I
think
a
new
document
would
be
the
preferred
I.
Don't
think
we
should
wait
for
this
and
I
think
we
need
time
to
discuss
any
issues
here.
Yeah
yeah.
G
Okay,
so,
if
you
add
this
stuff
into
the
RFC
will
get
it
banned,
it
will
not
only
not
get
implemented,
it
will
be
forbidden
to
be
implemented.
So
don't
start
messing
with
this
and
adding
it
like
a
zillion
additional
authentication
modes.
Do
it
separately
because
you're
talking
about
extremely
high
security
installations,
which
will
not
allow
PS
case
and
other
stuff
and
adding
a
zillion
modes
which
have
never
been
implemented
and
never
tested
is,
is
an
attack
on
on
on
national
security.
It's
not.
G
C
So
Bernard
this
Elliot.
The
reason
that
this
whole
conversation
came
up
was
that
we're
we're
working
out
actual
operational
flows
that
we
need
for
IOT
right
and
for
fallen
boarding,
and
so
that
we
see
the
value
in
using
TLS
PSK.
It's
defined
right.
So
the
question
is:
why
can't
we
use
a
mode
that
already
exists.
G
Another
code
point
for
it,
that's
fine,
but
if,
if
somebody's
the
point
is
it
was
forbidden
in
the
original
drafts,
it
was
forbidden
for
a
reason
it
was
because
it
there
was.
There
were
security
proofs
that
were
required
to
get
it
deployed.
Those
proofs
are
been
validated
by
what
you're,
adding
here,
okay,
so
so
people
wanted
to
do
very
specific
things,
and
only
those
things
and,
and
only
those
things
were
allowed
for
those
particular
installations.
There
were
very
high
security
certificate.
Based
things
want
to
do
something
else.
Just
get
another
code
point.
G
Do
it
there,
don't
add
all
of
these
all
of
this
additional
stuff
which
will
and
that
it'll
invalidate
all
the
security
proofs
that
are
there.
You
know
cause
a
ton
of
problems
and
because
of
that,
you
will
have
to
be
banned.
So
this
stuff
I
mean
you're
just
going
places
that
you
just
don't
go
there
just
get
another
code
point
and
you
know
do
it
separately,
just
so.
People
who
are
people
who
had
negotiate
this
particular
code
point
know
exactly
what
they're
getting.
D
C
I
Mohit,
no
hat
so
as
author
I
think
it's
it's
non-trivial
to
just
say:
yup
es
case
are
allowed
and
we
are
done
with
it
as
you,
as
we
have
seen
from
the
discussion
on
the
list.
There
is
all
these
questions
about
what
identities
to
use
whether
PS
case
using
epls
with
PS
case.
Should
we
allow
resumption
tickets
and
resumption
PS
case.
So
it's
not
a
done
deal
personally.
I
I'm
fan
of
small
modular
documents,
I
would
favor
so
I
agree
with
Myrna
that
probably
having
a
different
method
number
makes
sense,
anyways
or
type
code
and
then
having
a
separate
document
and
figure
out
the
issues,
as
we
kind
of
implement
this,
because
currently
TLS
PSK
at
least
is
not
implemented
in
in
the
open-source
WPA
supplicant.
So,
as
we
learn
along
the
implementation,
we
will
probably
need
to
make
make
changes
and
there's
no
point
holding
on
to
the
TLS
spec
until
that.
J
J
D
A
A
You
can
let's
take
a
hum
here.
This
is
something
I'm.
Pretty
sure
we'll
have
to
take
to
the
list.
First
question
will
ask
is
if
we
will
use
the
if
we
should
cover
EP
SK
in
the
same
document,
and
the
next
question
will
be.
If
we
should,
you
do
TLS,
PSK
and
a
different
document
so
hum.
If
you
think
we
should
do
it
in
the
same
document.
C
Have
to
have
some
discussion
on
the
list,
but
Elliot
yeah,
so
there's
a
reason
why
I
think
we
should
do
it
now
deal
with
it
now,
because
Alan
and
I,
and
a
couple
of
others
have
gone
through
all
the
effort
to
sort
through
these
issues
already
on
list,
and
we
we've
done
all.
We've
done
a
lot
of
the
work
we're
coming
close
to
closure
on
it
and
so
to
spin
up
another
document
to
have
to
do
it
has
to
causes
two
problems.
C
The
first
of
all,
it's
a
lot
of
work
to
spin
up
a
document
for
this.
The
second
issue
is
that
I
think
about
it
from
my
reader
standpoint,
which
is
okay.
Great
now,
I
have
to
essentially
I
have
to
come,
reconcile
two
documents
to
figure
out
how
I'm
going
to
do
my
implementation
and
I
think
that's
actually
more
complex
from
even
having
a
single
document.
Oh.
A
I
So
I
agree
with
the
one
also
I
don't
want
to
publish
an
expect
which
doesn't
have
implementation.
So
if
you
are
going
to
wait
until
the
TLS
PSK
implementation
has
move
forward
in
WPA
supplicant
this,
we
would
basically
hold
on
to
the
TLS
document
as
well,
which
is
more
or
less
ready
to
be
shipped.
So
that's
another
reason
why
I
want
to
do
it
separately
so
that
we
can
have
some
time
to
implement
and
learn
from
that.
It's
one
thing
to
say:
yeah.
I
A
Okay,
were
there
any
comments
on
jabber,
it's
okay,
all
right.
It's
so
I
think
we'll
continue
discussion
on
the
list
of
both
resolving
the
issues
with
PSK
mode
like
the
identity
issues,
I
think
are
primarily
the
issues
and
then
also
work
through
this
separation
of
the
documents
or
doing
it
at
one
document.
D
D
Relationship
between
identity
and
I,
when
using
external
PS
case
there,
there
has
been
quite
a
lot
of
discussion
even
suggestion
in
the
on
the
list.
As
yes,
gender
seems
to
be
a
greater
poem
that
when
using
external
PSK,
you
should
also
provide
a
realm
that
can
be
used
as
an
anonymous
nigh
and
then
discussion,
I
think
no
clear
answer.
It
should
be
distinguished
external
PSK
from
resumption
PS
case.
C
John
yeah
on
the
point
relating
to
providing
an
anonymous
nai
with
with
PS
k,
so
Alan
and
I
went
around
on
this
couple
times.
The
issue
we
have
to
be
careful
about
is
you
can't
always
use
that
anonymous,
nai
you
have
to,
or
it's
or
I'll
simply
break
frederick
federation.
I'm
you
have
to
be
somewhat
circumspect
as
to
how
you
use
the
anonymous
nai
so
for
enrollment
purposes.
C
Maybe
you
need
to
do
something
along
those
lines
if
you're
talking
about
t
p--,
for
instance,
but
you
can't
if
you're
already
enrolled
and
you
want-
and
you
want
to
essentially
use
the
nai
to
route
on
then,
which
is
not
an
unreasonable
thing
to
do.
We
do
it,
but
if
that's
the
pretty
massive
use
of
eep
at
this
point,
okay,
I
just
use
an
anonymous
nao
and
this
actually
impacts
eat
new.
It
back
steep
and
a
few
others
too.
Yeah.
I
You
can
still
do
Federation
and
routing
with
anonymous
nigh
as
long
as
the
realm
is
correct.
So
if
you
have
ever
used
at
your
home,
there
is
a
field
where
you
you
put
the
anonymous
knife.
As
long
as
you
put
the
correct
domain
part
in
the
realm
or
in
deny
your
authentication
request,
will
get
routed
to
the
correct
server
side.
I,
don't
I
think
there
was
an
incorrect
statement
to
say
that
you
can't
have
anonymous
nice
because
you
need
Federation
and
routing
sorry.
C
Sorry,
what
I
meant
to
say
you
know
he's
right.
Well,
we're
there's
a
separate
discussion
and
I
mix
them
up.
There's
a
separate
discussion
going
on
about
when
to
use
a
standard
realm
identifier
and
that's
where
things
can
break
Federation,
that's
and
so
you're
right,
you're,
absolutely
right!
You
can
use
anonymous
any.
D
Fourth
bullet
is
to
distinguish
between
external
PSK
and
resumption
PSK
and
officially
and
be
any
guidance,
I
think
the
it
might
be
hard
to
control
both
of
these
external
peers
case.
You
might
have
control
of
might
also
come
from
some
other
source.
You
might
want
to
reduce
existing
identities
in
the
organization
and
derive
identities.
D
From
from
that,
the
internal
resumption
peers
case
are
typically
decided
by
the
TLS
application,
so
the
EAP
implementation
might
or
might
not
have
an
influence
on
that,
depending
on
how
much
they
want
to
reuse
or
me
mess
with
a
TLS
code,
but
I
think
these
are
both.
Of
these
things
are
things
that
should
be
discussed,
but
I
don't
think
we
can
end
up
in
any
must
look
like
this.
It's
more
like
guidance.
E
K
Our
Dan
Harkins
already
done
with
this
slide
after
yeah,
so
you
mentioned
the
CFR
G
is
working
on
a
pig
selection
process.
So
if
we
do
separate
things
and
have
T,
let's
1.3
as
one
document
and
PSK
is
a
different
document.
Why
don't
you
want
to
wait
for
the
PSK
one
and
just
to
do
a
peg,
because
it's.
K
You
gonna
do
it
diffie-hellman
in
the
PS
k.
Yes,
then
it's
not
bene.
I
mean
it's
like
a
diffie-hellman
and
a
half
to
do.
Okay,
yeah
a
balance,
pay
right!
You
could
do
something,
that's
considerably
more
than
a
diffie-hellman
and
a
half,
but
I
mean
I
I.
Think
would
behoove
this
group
to
wait
a
little
bit
to
do
the
right
thing,
because,
even
with
doing
it
diffie-hellman
it's
still
susceptible
to
a
offline
dictionary
attack
after
an
active
attack,
so
I
think
using
a
pig
would
probably
be
a
really
good
idea.
Yeah.
D
I
think
if
you
use,
if
you
use
password
with
the
PSK
brochure,
it's
weak,
I
think
passwords
MPs
case
or
some
sometimes
people
misuse
it,
but
otherwise
it's
different
use
cases.
You
have
PSK
in
IOT,
where
you
have
some,
so
you
have
some
distribution
system
of
these
PS
case
and
that's
secure
them.
When
you
have
human
involves
setting
things
up,
then
you
have
passwords
yeah.
E
Forgive
me
I
was
about
to
come
at
the
same
thing.
A
PS
k
is
PS
k,
businesses
say
it's
appreciate
key,
it's
not
password
yeah,
it's
a
strong,
long,
entropy
and
in
the
IOT
environment.
It
actually
might
be
that
in
for
lots
of
the
other
environments.
It
isn't
so
that's
why
I
think
that
there
is
still
a
use
for
especially
in
IOT
environment
for
EAP,
a
PPS
K
in
that
case,
because
it
might
be
even
even
if
it's
a
little
bit
only
foster.
It
still
might
be
enough.
There
I.
K
Think
we
should
all
disabuse
ourselves
to
the
notion
that
you
know
the
guidance
we
recommend
in
in
the
security
considerations
of
an
RSC
is
how
it
ends
up.
Getting
used
and
saying.
Well,
PSK
is
a
PSK
and
on
a
password,
and
therefore
people
will
use
PSK
with
PSK
eat
a
big,
long
giant
strings
and
not
not
with
passwords,
because
we
know
that
they're
not
going
to
do
that.
People
use
the
tools
that
they
have
and
they
sometimes
use
them
wrong.
E
We
can't
prove
to
idiots
I
mean
if
they
use
make
me
a
tasty
code
as
their
password.
It
doesn't
matter
if
our
if
using
pay
core
PSK,
if
the
part,
if
the
password
is
same
for
everybody,
I'd
known
by
that
you
know
everybody
so
so
I
mean
it's,
nobody
follows
or
of
any
of
anything.
What's
right,
we
are,
you
know
losing
anyway.
If
they
use
weak
passwords
one
letter
passwords.
It
really
doesn't
matter
whether
you
are
using
fake
or
PSK.
Alright,.
K
A
L
K
A
A
A
D
Can
we
I?
Am
you
only
see
the
atom
in
four
PS
km
for
certificate?
Extensions,
I,
don't
know
if
there
is
something
specific
for
each
LS.
In
that
case,
we
should
make
sure
to
very
concretely
take
that
discussion
on
the
list-
yeah,
okay,
next
yeah,
so
this
is
about
certificate
handling
and
I
have
serious
slides
on
this.
M
M
M
M
Clearly,
people
should
be
allowed
to
do
other
things
if
they
want,
but
then
it
won't
be
compatible
with
roaming,
which
is
a
very,
very
common
use
case.
So
if
you
go
to
the
next
slide,
there's
some
additional
discussions,
so
this
is
sort
of
the
summary
of
which
identities
are
where
you
have
the
username,
which
is
used
in
triple-a,
routing
the
eep
respond,
slash,
identity
and
then
the
PSK
identity
or
certificate
common
name
which
is
commonly
used
in
TLS
they're,
often
the
same.
They
don't
have
to
be
I.
M
M
M
Username
for
P
TLS
or
R,
or
T
TLS,
with
TLS
1.2
SOF
identities,
exactly
the
common
name,
because
there's
the
certificates,
they're,
usually
public
for
TLS
1.3
key
identity
should
be
anonymized.
So
we
can
say
that
generally,
instead
of
having
the
user
configured
two
different
things
on,
we
could
just
say
the
comment.
The
EP
identity
is
derived
from
the
common
name
by
using
the
realm
portion,
so
it's
routable
and
maintains
user
privacy.
So
next
slide.
M
So
for
PSK
identities,
whether
or
not
we
allow
ETLs
use
PSK
for
pre
provisioned
PSK
identities,
we
can
recommend
using
the
NAI
form
when
we
know
that
works
or
if
there's
a
need
for
identities
which
do
not
match
the
NIE
requirements.
We
can
just
say
people
use
whatever
they
want
for
the
PS
key
identity
and
then
separately
use
the
NAI
for
the
eep
identity
right.
So
the
idea
here
is:
it
doesn't
really
matter
what
the
PST
identity
is.
M
We
know
that
the
anonymous
Nai
you
always
works
for
routing
I'm
super
go
to
the
next
slide
and
resumption.
The
eep
application
doesn't
necessarily
control
the
derivation
of
the
PST
identity
for
a
resumption.
So
it's
safest
to
assume
that
it's
just
it's
opaque
blob,
which
is
not
utf-8
and
not
an
nai
and
therefore
cannot
be
used
for
the
EEP.
So
again,
we're
left
with
and
nonnamous
nai,
which
then
allows
the
assumption
to
be
routable
and
decouples
routing
from
the
PSG
identity.
M
So
we
can
use
different
identities
for
every
resumption,
which
gives
us
some
level
of
privacy,
even
though
the
MAC
address
is
usually
they're
always
the
same,
and
then
it
doesn't
affect.
Read
ability
of
the
packet?
Some
of
my
earlier
comments
were
that
the
resumption
session
should
use
the
same
EEP
identity
as
the
original
authentication.
M
M
C
Alan,
it's
Elliott,
I,
really
mostly
agree
with
pretty
much
everything
you
said.
I
had
a
question
about
handling
normal
TLS
certs.
If
you
go
back
to
like
that,
that
slide
not
PSK,
but
just
the
the
other
other
form
of
a
is
your
presumption
that
there
is
something
that
approximates
a
realm
within
the
cert.
M
That's
a
whole
effort
discussion
as
to
where
that
nai,
which
which
field
of
the
cert
that
nai
comes
from,
is
a
separate
discussion
with
I
for
now
I'm
just
waving
my
hands
and
going
it's
in
there
somewhere.
If
the
search
says
it's
for
example.com,
we
probably
want
to
use
example.com
in
the
identity
as
an
anonymous
realm.
C
M
Don't
think
it
has
other
anonymous
implications.
This
is
really
the
text
on
this
slide
is
really
more
just
background
as
to
what
people
mostly
use
now
in
the
common
on
derivation,
the
common
practice,
and
after
going
through
this
and
sort
of
running
down
the
checklist
of
all
the
different
possibilities,
everything
comes
out
with
use
the
anonymous
nei,
so
I
think
that
should
be
the
recommendation
in
depend.
Why
it's
worth
having
an
explanation,
but
it's
worth
also
just
having
the
recommendation
of
you
know
just
use
the
anonymous
nai
everywhere,
always
no
matter
what.
D
Yeah
you're,
not
sorry,
you
say
that
it
should
be
a
recommendation,
but
the
EPL
s103
draught
will
already
have
a
recommendation.
It
says
that
anonymous
knives
are
mandatory
to
support
and
recommended
to
use
so
I.
Don't
I,
don't
really
see
concretely
what
you
are
when
we
think
for
this
certificate
use
case
for
the
biggest
Kay
use
case.
You
have
local
other.
M
I'm
speaking
as
an
implementer
I
I
guess,
the
text
on
identities
is
buried
inside
of
the
resumption
section.
So
it's
not
clear
that
for
normal
authentication
you
should
use
the
anonymous
nai
I.
Had
some
tax
I
sent
to
the
list,
I
think
I
also
open
a
github
request.
I
think
it
would
help
to
have
a
separate
section
in
the
document
saying
identities
which
you
can
then
discuss.
Hey
some
certificates
have
these
identity,
some
don't
for
resumption.
M
In
any
case,
for
this
list
of
reasons,
here's
why,
for
ETLs,
the
eep
identity
should
be
the
anonymous
nai
realm,
because
I
guess
for
me
it's
it's
not
clear.
If
that
text
is
buried
in
the
resumption
section,
it's
not
clear
to
me
as
an
implement
or
reading
this,
that
this
field,
which
is
separate
from
resumption,
should
have
a
particular
value
for
particular
reasons.
Sure
so.
G
Mobile
mic
resistant,
which
is
that
you
know
at
in
some
systems.
I
have
seen
the
radius
server,
make
different
suggestions
of
different
methods
for
different
people
right.
So
what
that
means
is
that
there
can
be
more
than
one
I
done
more
than
one
anonymous
in
AI
used
by
our
an
organization
say
they
decide.
I
security
users
are
going
to
all
be
forced
to
use
the
apt.
Less
and
lower
security
users
use
something
else,
teep
whatever,
and
it's
worth
thinking
that
the
the
AP
identity
right
is
not
method
specific.
G
It's
for
any
method,
so
we're
really
talking
about
here
kind
of
upgrading
privacy
for
really
everything
not
really
specific
to
EB,
TLS
and
I.
Guess.
My
point
is
that
when
you're
asked
for
an
identity,
you
don't
necessarily
know
what
method
you're
going
to
use
so
saying
this
is
this:
is
the
identity
you
should
use
for
EB
atilla's?
Those
are
not
necessarily
correlated
with
each
other.
Oh.
M
Okay,
yeah
I
mean
to
a
certain
extent,
yes,
but
I
think
we
still
need
to
have
some
recommendation
for
the
implementers
of
ETLs
as
to
when
they're
trying
to
negotiate
TLS.
They
need
to
have
a
have
an
initial
starting
point
for
the
identity
and
that's
where
the
recommendation
of
this
anonymous
nei
comes
from.
M
M
The
text
in
the
document
is
sort
of
my
initial
stab
in
the
dark,
but
it
would
be
good
to
actually
have
some
review
of
that
for
fast
and
maybe
something
from
implementers
saying
that
this
works
and
there's
interoperable
but
I,
don't
think
anyone's
really
done
much
of
anything
with
with
fast
and
TLS
1.3
I
think
based
on
discussion
on
the
list.
The
T
pop
dates
probably
belong
here
and
then
I
think
the
document
should
be
published
close
in
time
to
the
ETLs
document.
M
I
know
the
the
response
from
Microsoft
was
that
they
wouldn't
touch
anything
including
epls
until
they
could
rev
all
the
other
TLS
types
or
TLS
based
EGH
types.
I
know
that
e
TLS
is
implemented
for
TLS
1.3
is
implemented
in
WPA,
supplicant
I,
don't
think,
there's
been
any
progress
on
P
port
or
TTLs
they're.
The
same
thing
in
my
implementation,
mostly
because
we're
not
really
sure
what
to
do
so.
M
If
we
can
get
some
additional
feedback
here
and
I
think
we
can
get
the
various
open
source
people
to
update
everything
and
implement
everything,
and
then
we
know
it
works.
I
think
we
just
need
consensus
from
the
working
group
that,
yes,
this
is
okay
and
we
should
we
should
be
moving
forward
with
this.
A
So
are
you?
Are
you
in
touch
with
folks
who
can
help
with
teep
information,
because
I
think
that's
been
a
common
open
issues
that
we
have
some
errata
still
open
and
there's
been
some
discussion,
but
not
quite
enough
and
I
know
folks,
are
talking
about
implementations
want
to
make
sure
that
we
have
the
right
folks
involved
so
that
we
can
get
the
document
updated
in
a
reasonable
amount
of
time.
So
the
word
out
to
implementers
yeah.
M
M
M
My
inclination
is
that,
given
that
peep
and
TTLs
are
more
widely
used
than
teep
and
easier
to
update,
if
there's
any
concern
of
a
teep
that
causes
delays
of
this
document,
I
would
prefer
just
to
drop
fast
and
teep
and
just
have
a
reference
of
you
know.
This
is
what
we
think
might
work,
but
we're
not
really
sure
and
then
read
it
later,
so
that
we
can.
We
can
rev
TLS
and
teep,
so
int,
TLS
and
peep
all
at
the
same
time,
which,
which
are
extremely
widely
used.
M
A
A
L
B
L
I'll
give
an
overview
of
e
noob
and
next
slide.
Please
so
I'll
start
with
a
quick
overview
of
the
protocol,
then
the
draft
status
and
then
at
the
end,
I
have
a
couple
of
technical
issues
that
may
be
of
interest.
One
is
how
we
use
deny
and
then
about
roaming.
Okay.
So
what
problem
does
a
be
noob
into
soul?
Well,
as
we
know
this
currently
no
out
of
mana
indication
method
for
EAP
and
the
need
for
this
method
has
now
been
identified
in
the
new
charter
for
the
working
group
and
ap.
L
For
example,
the
user
could
scan
a
dynamic
QR
code
or
endeth
tag
or
read
a
blinking
light
with
a
mobile
phone
to
deliver
the
out-of-band
message
between
the
peer
and
the
server,
and
this
is
a
bootstrapping
method
so
that
when
the
out
of
band
or
the
dictation
takes
place,
the
device
is
also
registered
at
the
triple-a,
and
then
it
could
that
registration
will
later
be
used
for
a
fast
reload
indication
of
the
pre
of
the
register
devices
so
that
no
more
user
interaction
or
other
bad
communication
is
needed.
Next
slide.
L
L
So
here
is
a
summary
of
the
draft
status.
I
think
it's
pretty
mature.
Now
we
have
two
implementations.
There
is
the
implementation
for
WPA,
supplicant
and
hostapd
done
at
other
university
and
then
kentucky
implementation,
mainly
at
University
of
Murcia
in
Spain,
and
then
we
have
model
the
protocol
with
formal,
modeling
and
verification
tools
on
one
hand,
the
protocol
state
machines
and
in
our
service
resistance
properties,
and
then
the
security
protocol
and
authentication
and
I
think
once
the
new
charter
updated
Charter
is
confirmed.
L
If
there
is
no
roaming,
then
they
can
continue
to
use
the
generic
real
man,
but
the
usually
I
guess
it
would
be
good
to
assign
realme
for
roaming
Persis.
So
this
is
how
we
have
solved
this
night
problem
with
the
unregistered
devices
in
the
beginning
and
then
next
slide.
Actually,
you
can
go
one
more
if
I
use
the
picture
other
than
the
text,
so
I
want
to
explain
a
roaming
question
or
a
problem,
how
we
handle
roaming
and
then
what
still
hasn't
been
done
about
it?
L
In
the
initial
exchange,
the
Triple
A
assigns
a
peer,
ID
and
real
OMA
to
the
device
next
slide
and
later
the
same
device.
If
it
moves
to
different
parts
of
the
network,
it
can
use
that
assigned
na
for
roaming
just
as
normal.
There
is
nothing
specific
special
about
this,
and
this
works
well
with
the
current
EAP
noob
specification.
L
So
that's
the
kind
of
roaming
that
we
currently
support,
then
in
the
following
two
slides
I
want
to
talk
some
kind
of
what
could
be
done
so
now
here
is
a
user
who
is
already
at
the
other
parts
of
the
network
and
not
in
the
whole
network
and
in
this
for
a
network,
it's
wondering
when
it
has
just
purchased.
The
first
device
is
wondering
why
it
can
register
that
next
slide.
L
The
problem
they
have
is
that
we
would
need
to
route
the
radius
requests
from
this
forum
triple-a
to
the
home
triple-a,
and
then,
if
that
was
possible,
then
we
could
do
the
authentication
with
the
EAP
noob,
but
because
the
device
now
has
the
generic
ID
and
realm',
it
cannot
really
connect
your
home
or
the
load.
The
foreign
triple-a
doesn't
know
where
to
route
this
request:
where
does
the
user
want
them
and
we
don't
currently
have
a
technical
solution
then
next
slide?
L
This
is
the
final
slide,
so
the
we
think
that
there
could
be
some
mechanism
for
the
user
to
interact
with
the
foreign
triple-a.
Let's
say
a
webpage
where
it
can
request
routing
of
the
radio
requests
for
the
new
device
to
the
home
triple-a,
and
that
would
enable
registration
of
new
devices
while
roaming,
and
this
only
needs
to
be
done
once
and
what
then,
when
the
EAP
new
Association
has
been
created,
the
reordan
dication
will
again
work
as
normal
roaming
without
any
such
special
interaction.
L
N
O
Vision,
wattage
area
from
thesis,
research,
India,
so
I
have
a
few
comments
from
different
logistics
perspective.
The
thing
is
that
in
Bangkok
I
mentioned
that
considering
the
startup
community
growing
in
the
subcontinent
level,
what
we
have
seen
is
that
there's
a
gap
in
terms
of
securing
this
I
mean
the
knowledge
in
terms
of
securing
their
devices
properly,
so
they
have
good
sensor
knowledge.
They
have
good
knowledge
on
the
basic
hardware,
but
this
kind
of
solution
as
a
plug-in
can
actually
help
them
for
a
better
service.
O
But
the
problem
in
terms
of
adopting
the
solution
that
I
see
is
that
when
these
companies
they
go
to
market
their
end,
customer
would
not
like
to
use
anything
which
is
non-standard
and
also
implementation.
Wise,
getting
the
the
numbers
from
Ayane
is
very
important,
because
people
don't
really
like
to
change
nativities
inside.
So
probably
if
it
is
technically
I
mean
it
is
at
some
stage,
and
there
are
implementations
already
available,
open
source,
probably
pushing
it
for
adoption,
and
standardization
might
might
find
a
new
opportunity.
That's
all
I
wanted
to
say.
C
A
P
P
The
practical
process
in
case
what
we
did
is
the
Charter
result
first
comes
to
the
ice
tree
for
a
quick
look.
Are
you
okay
with
that?
Yes,
we're?
Okay
with
that,
then,
let's
go
to
the
community.
Is
the
community?
Okay,
with
that
and
based
on
the
community
comments
and
then
comes
back
to
the
is
G
okay,
you
heard
from
the
community.
Are
you
now
really,
okay
with
it,
and
then
it
gets
approved.
D
R
S
A
Q
A
C
This
will
be
a
pretty
short
presentation.
I
hope
next
slide.
Please
all
right!
Well,
these
so
we've
only
been
subtle
to
small
changes
to
eat
deep
risky,
but
larger
changes
are
coming.
The
first
is
that
the
doctor
that
all
the
diagrams
have
been
simplified.
There
was
a
lot
of
hopping
over
things
and
where
didn't
we're
in
the
swimming
line
diagrams
from
UML
that
didn't
need
to
happen,
and
so
we
cleaned
a
bunch
of
that
up.
So
that's
done.
C
C
I
think
here
I
think
we
want
to
broaden
out
the
this
to
a
teep
update,
maybe
even
de-emphasize
the
brewski
part
in
this
just
make
it
more
of
a
Jenner
generic
teep
update,
but
also
keep
you
know
the
additional
opcodes
titl
bees
for
brewski,
and
so
this
ties
to
a
couple
of
different
things
next
slide.
Please
so
here
are
all
of
the
errata
14.
I
Might
so
I
just
had
a
very
short
comment
on
on
this
doing
the
update
of
deep
and
brewski.
So
what
I
apply
to
my
own
drafts?
I
I,
don't
ask
you
to
do
anything.
What
I
don't
do
myself
so
I
kind
of
recommend
it
to
myself
to
split
the
PSK
part
out.
I
would
kind
of
recommend
the
same
thing
to
you
to
put
the
brewski
part
in
a
separate
Draft
and
fix
the
tea
Parata
as
a
separate
document.
I
The
reason
I'm
saying
this
is
because
now
teep
is
finally
getting
implemented
in
in
Windows
and
and
in
other
places
and
which
is
very
nice
and
we
should
kind
of
fix
the
writin
in
in
one
document
and
I'm,
not
sure
if,
like
all
use,
cases
would
use
brewski
and,
like
my
Windows
laptop,
probably
won't
come
with
I'll
divide,
eaj,
divide,
E's
and
so
on.
So
maybe,
as
I
said,
I'm
a
fan
of
small
modular
document,
so
maybe
splitting
them
up
makes
sense.
Yeah.
C
And
I
tend
to
think
of
it
as
the
opposite
actually
Mohit,
because
from
an
implementer
standpoint,
if
I
have
to
end
up
reading
a
hundred
documents
to
implement,
implement,
teep
or
actually
they're
peeps,
not
the
worst
offender
here.
But
there
are
a
couple
of
protocols
in
the
ITF
that
are
really
bad
because
you
had
to
really
have
to
sift
through
a
lot
of
documents.
I
don't
want
to
start
down
that
road.
If
we
can
get.
C
C
And
there
are
a
couple
of
things
here
that
are
well
outside,
say
the
voucher
aspects
of
ruski
that
probably
are
worth
capturing
and
teep
that
we
that
just
got
missed
the
first
time
around.
So,
if
instance,
the
get
CSR
attributes
function
that
that's
in
that's
in
brewski,
probably
is
something
that
is
needed
more
in
an
EST
log
function,
which
is
what
teep
tracked,
and
so
you
probably
want
to
keep
that
one
way
or
the
other.
Even
if,
at
the
end
of
the
day,
we
decided
to
drop
all
the
brewski,
the
rest
of
the
voucher
ones.
C
There
are
other
aspects
here
too,
which
is
if
we're
going
to
open
up
t
p--
Draft.
There
may
be
a
couple
of
other
tlvs
that
we
want
to
add
in
any
case,
I'll
come
to
that
in
a
moment,
I
went
through
all
of
the
the
the
errata,
and
some
of
them
are
really
straightforward.
Right
I
mean
you
have
typos
in
various
places
that
sorta
caught,
for
instance,
and
some
of
them
are
also
really
rather
simple
clarifications.
C
C
C
So
I
think
these.
These
are
the
list.
It's
not
a
huge
list,
and
it's
just
something
I
think
we
could
knock
through
over
the
next
couple
of
I
want
to
say
next
couple
months,
we're
probably
it's
going
to
take
a
couple
of
cycles.
The
meetings
actually
to
make
sure
we're
comfortable
with
this
next
slide.
Please,
okay!
C
But
if
we're
not
gonna,
if
it's
not
going
to
be
too
slow,
then
let's
just
proceed
and
see
how
far
we
get
so
I
think
there's
one
more
side
right,
so
yeah
there's
this
interaction
aspect.
So
how
does
teep
interact
with
other
802
11
capabilities
and
EPP
in
particular?
How
do
you
do
network
selection
from
wireless
and
how
you
bind
from
a
DPP,
applicator
Madi,
PP
transaction
into
t
p--?
C
If
you're
going
to
do
that,
and
some
of
that
has
to
be
worked
out
architectural
and
this
ties
to
the
discussion
that
we've
been
having
about
you
know:
how
do
you
how
these
building
blocks
look
together
and
what
does
that
mean
from
a
from
a?
How
do
we
discuss
that
at
the
IETF,
so
I
don't
want
to
blow
up
the
you
know
this
into
a
huge
issue.
It's
it's
really,
not
I,
don't
think,
but
we
are
tying.
This
is
a
little
bit
bigger
than
just
teep
next
slide.
C
Okay,
so
you
know,
one
of
the
things
we
can
do
is
just
have
a
section
that
goes
through
and
accepts
you
know
or
provides
an
update
on
on
how
we
deal
with
the
errata.
Then
we
have
another
issue,
which
is:
how
do
we
deal
with
TLS
one
three
I
sort
of
like
the
idea
of
having
that
done
and
the
other
document
that
Alan's
doing?
C
C
That
goes
not
yet
we're
ready
for
release,
because
it's
slightly
embarrassing
in
terms
of
one
or
two
points
and
I
would
rather
not
be
quite
that
embarrassed,
so
I
think
at
the
end
of
the
day
you
know,
probably
in
March
the
document
will
look
a
little
bit
cleaner
in
terms
of
how
this
looks,
and
that
will
be.
That
will
give
you
a
good
view
as
to
whether
or
not
to
adopt
it's
the
way.
I
see
it,
and
that
would
be
that
where
I
would
leave
things
for
now,.
A
A
C
Here's
what
I
propose
then
Joe
I
will
take
as
an
action
to
post
it
to
post
these
each
as
an
issue
right
each
of
the
errata
as
an
issue
with
a
proposal
how
to
address
I
suggest
the
chairs
track
them
as
separate
issues
right
and
then
you
guys
have
the
option
of
closing
or
not
and-
and
you
know,
based
on
the
working
groups
view
and
then
when
once
the
as
as
we're
doing
that
in
parallel,
we
can
also
deal
with
the
other
deep
work.
That's
being
done.
A
T
Please,
okay,
so
problem
statement,
I
work
for
Kaiba
labs,
so
we
have
our
members,
our
operators
that
tend
to
deploy
a
different
type
of
networks
from
Wi-Fi,
with
public
access
point
to
cellular
networks,
CBR
s
which
is
practically
4G
and
Phi
G
doing
in
unlicensed
spectrum
like
multi
fire
or
our
networks
like
the
Oxus
networks.
Right.
T
However,
this
one
one
problem
that
our
members
always
report,
it's
very
difficult
to
manage
to
dynamically,
manage
these
credentials
for
their
access
networks,
and
they
really
would
like
to
have
the
possibility
to
change
these
credentials
depending
on
the
risk
level
that
that
is
that
they
want
to
set
in
the
networks
right.
So
today
is
very
difficult
for
them
to
have
a
centralized
system
that
does
this
across
different
networks,
different
technologies
next
slide
and
of
course
we
don't
use
one
type
of
credentials.
We
use
different
type
of
credentials
like
username,
password,
secret
keys
and
certificates.
T
So
certificate
is
one
of
them
and
you
know
usually
having
multiple
methods
can
improve
device
diversity
in
your
in
your
network
sometimes,
and
the
possibility
to
switch
between
between
type
of
credentials
and
security
manages.
This
credential
is
not
easy
right,
so
we
seen
some
proposals
to
manage
credentials
through
through
EEP,
but
there's
no
consistency
about
being
able
to
manage
all
type
of
credentials.
T
So
what
are
we
trying
to
focus
with
our
work
so
that
work
is
trying
to
provide
an
encapsulation
mechanism
right
so
that
you
can
use
your
own
provisioning
mechanism?
And/Or
encapsulate
standard
mechanism
that
already
exists?
Why
do
we
think
this
is
a
a
good
approach
right?
We
work
in
many
different
vitamins
like
that
bf,
a
for
example,
where
they
use
a
different
approach.
They
propose
that
devices
get
their
own
IP
address,
get
in
jail.
State
basically
can
reach
a
also
server,
which
is
a
online
sign
up
server
and
then
from
there.
T
Then
we
can
get
their
credentials
and
then
authenticate
to
the
network.
However,
you
know
some
operators
reported
that
they
don't
feel
comfortable,
deploying
these
type
of
solutions,
because
now
you
have
devices
that
are
not
authenticated
and
they
can
probe
your
network
because
they
have
IP,
so
they
have
relative
bility.
We
think
that
this
solution
solves
this
problem,
because
now
you
cannot
route
your
message
and
it's
from
a
security
standpoint
of
view.
It
makes
a
lot
of
sense
and,
as
before,
I
suggested
also
for
brewski.
T
We
think
that,
with
our
protocol
being
generic,
you
can
have
profiles
for
that
for
your
use
case,
and
so,
for
example,
if
you
want
to
implement
a
full
set
of
standard,
you
know
like
est,
you
can
print
the
full
est
or
you
can
just
implement
the
renewal,
because
that's
the
use
case
that
that
makes
sense
for
you
next
slide,
so
just
very
briefly,
Ameri
quickly.
Well,
how
we
organize
the
EEP
creds.
We
try
to
provide
three
different
phases
for
now:
the
initialization,
the
management
and
the
validation.
T
The
initialization
is
the
part
that
you
can
use
to
bootstrap
the
process.
You
can
use
tokens
or
voucher
that
can
be
bear
tokens
or
can
be
tied
to
a
key.
So
there's
all
methods
that
you
can
use
for
authentication,
but
basically
this
the
initialization
says
the
device
says:
oh,
these
are
the
credential
they
have
for
your
network.
Do
you
want
to
do
something
with
it
and
then
basically,
the
the
server
can't
start
if
he
wants
to
I
started
management,
please
where
you
can
renew
or
deploy
new
type
of
credentials.
T
It
is
supported
by
the
device
and
then
optionally
verify
that
actually
what
the
device
has
corresponds
to
what
the
server
thinks
you
should
have
next
time.
So
what
has
changed
so
far?
Well,
we
simplify
the
proposal
because
we
receive
feedback
from
the
from
the
workgroup.
These
are
documents
are
very
long.
We
want
them
to
simplify,
so
they
can
be
understood
better.
So
we
we
decided
well
from
from
the
Middle
East.
They
said
it's
okay.
T
But
at
the
same
time
we
add
a
new
text,
because
one
of
the
item
that
was
left
over
was
to
define
one
basic
protocol
that
could
handle
all
different
type
of
credentials.
I
recall
now
SPP
or
simple
provision
in
protocol,
but
it's
just
a
very
simple
thing,
and
basically
this
try
to
provide
one
method.
So
it's
not
the
only
method,
so
they,
the
it
creds
is
meant
to
be
an
encapsulation
method
and
next
slide.
Because
of
this
right,
we
thought
about
simplifying
the
the
document
by
removing
the
SPP.
T
Now
there
are
some
other
things
that
we
might
and
you
might
simplify
the
document
to
make
it
even
shorter,
but
I
hope
we
can
do
it,
then
the
next
in
the
next
version
of
the
draft
next
slide.
Of
course,
I
want
to
thank
everybody
that
really
helped
us
in
making
the
proposal
better
and
also
in
the
chairs,
because
they
charted
text
has
been
a
longtime
discussion
and
finally,
we
get
we
get
there
yeah.
Thank
you.
So
much
next
slide.
T
So
what
are
what
I
request
here
so,
of
course
we're
focusing
on
the
use
case
that
makes
sense
for
our
members,
because
this
is
something
we
want
to
deploy
in
our
networks.
We
also
working
with
CBR
s
where
I
think
on
the
14th
was
the
four
released.
Three
EPs
was
a
lot
adopted
to
manage
the
credentials
for
cellular
networks
for
CBR
s
networks,
then
we're
working
also
with
the
wireless
broadband
Alliance
they
were
interested
in
to
see.
T
T
We
don't
think
that
the
document
is
ready
for
thinking
about
adopting
in
the
workgroup.
We
want
to
simplify
that
and
make
some
tweaks
before
before.
We
think
is
ready
for
evaluation,
but
we
hope
that
we
can
do
it
soon
and
maybe
by
the
night
next
time
we
can
think
about
adopting
it.
This
is
the
reference
for
the
current
ID
that
we
have
I
know
it's
very
in
his
late
and
you
have
the
eyes
very
open.
But
if
you
have
any
question,
please.
U
Aha,
you
know
a
lot
of
IOT
or
device
onboarding
procedure.
Usually
we
have
some
Pro
provisioning
or
create
credential
on
the
device
and
we
use
it
for
the
authentication
and
for
the
later
network
set
control.
So,
but
here
you
propose
that
we
we
through
the
credential
provision,
you
know
when
the
device
is,
is
joining
the
network.
So
I
don't
know
the
relation
between
the
you
know
the
current
method
and
what
is
the
typical
use
cases
for
your
method?
T
With
the
with
this
method,
actually
you
can
still
continue
to
use
that
that
approach
in
the
sense
that
when
you
do
an
initialization
phase,
if
the
device
doesn't
have
as
some
credentials
that
you
may
leverage
to
register
the
device
that
happens
in
the
to
initial
message,
so
there's
two
messages
in
the
initialization
phase
and
you
can
use
that
that
method
to
leverage
credentials
that
already
exist.
But
on
top
of
that
you
can,
you
can
decide
well
I
like
these
credentials.
This
is
the
credentials,
for
example,
that
were
put
there
for
certification.
T
You
have
an
Aussie
F
device.
You
have
you
know
some
devices
that
have
certification
already
certificate,
but
that
particular
method
of
authentication
for
your
network.
You
don't
think,
is
appropriate.
Oh,
let's
put
it
this
way.
You
want
to
change
so
you
can.
You
can
use
that
credentials
to
register
the
device
and
then
deploy
the
credentials
that
you
would
like
the
device
to
use
the
next
time
they
they
accident
or
something
like
that.
So
think
about.
You
might
have
a
voucher.
T
You
might
have
something
that
is
tied
to
a
key
or
not,
or
just
presenting
one-time
token
right
to
register
the
device
that
you
obtain
from
a
website
somewhere.
We
don't
specify
that
this
is
outside
the
scope
of
the
of
the
protocol,
but
they
are
use
case,
for
example,
for
adaxes
network
or
CB
RS.
Is
you
have
some
sim
credentials?
T
C
Hey
max
so
I
think
what
your
there's
a
lot
here,
that
you're
doing
that
I
think
is
really
interesting,
because
it
attracts
precisely
to
this
morning's
conversation
right
in
terms
of
how
we
onboard
with
IOT
I.
Have
one
I
have
one
major
concern?
Well,
it's
one
major
concern,
but
it's
it's
a
lengthy
one.
C
What
we
are
suffering
with
in
IOT
right
now
is
fragmentation
of
all
this
and
I
realize
you're,
trying
to
defragment
by
by
finding
at
least
one
consolidation
point,
but
I'm
concerned
that
with
so
many
mechanisms
it
actually
won't
consolidate,
and
so
one
of
the
things
that
we
talked
about
this
morning
was:
can
we
distill
down
architectural
II?
What
is
really
needed
to
bind
between
these?
You
know
the
input
process
for
for
eep.
C
If
you
will
versus
the
output
process
from
what
came
before
and
I
wonder
if
we
want
to
just
take
a
step
back
a
little
bit
as
we
go
through
that
and
say:
ok
can
we
can
we
distill
this
down
to
something
like
we
discussed
this
morning
as
as
a
you
know,
something
like
an
EDC
sa
public/private
key
pair
or
something
along
those
lines?
Maybe
the
public
EDSA
is
a
little
ETCs.
A
is
probably
a
little
too
specific
right.
C
You
probably
need
a
code
point
approach,
and
this
and
I'm
not
even
sure
about
how
to
manage
the
code
points
in
that
regard.
But
if
we
can
distill
that
down
then
there's
another
opportunity
here.
The
other
opportunity
is
that
our
two
drafts
merge
right
and
we
sort
of
proceeded
forward
along
those
lines.
C
Do
you
want
to
throw
us
SCEP
and
in-ears,
for
instance-
and
you
know-
and
I
think
there
are
some
use
cases
that
they
have,
but
that
that
needs
to
be
reviewed
in
this
context.
So
as
all
as
part
of
this,
if
we
can
distill
this
down,
then
we
can
reduce
the
fragmentation
and
that
will
accelerate
deployment.
T
Yeah
Elliot,
thank
you
for
the
question
yeah.
Definitely
if
we
can
maybe
merge
the
two
proposals,
if
we
you
know
they
both
fit,
they
use
cases
great,
less
work
and
better
work
and
so
far
architecture
wise
they.
What
we
are
working
on
is
try
not
to
put
architecture
in
this,
but
lets
you
decide
the
architecture.
So
this
comes
from.
You
know
the
our
operators.
They
usually
have
some
purchasing
power
for
devices
so
that
that
usually
helps
them
to
have
more
freedom
when
they
have
to
decide
how
to
manage
the
credentials.
T
But,
coming
to
the
point
that
you
were
saying
about
the
you
know,
defining
all
this
fragmentation
for
these
provisioning
protocols,
I
totally
agree
with
them.
We
have
that
problem,
and
this
is
not
a
new
problem.
You
know
whenever
you
need
to
implement
a
provisioning
protocol,
you
have
to
choose
which
one
which
option
not
that
provisioning
protocol
cetera.
That's
definitely
true.
T
My
plan
is
not
to
to
do
this
work
for
every
protocols
that
we
have,
as
I
said
before,
we
have
a
proposal
for
the
SPP,
which
is
very
simple
meant
to
be
version,
not
super
flexible
and
like
other
programming
protocol,
but
sufficient.
Let's
boot,
it
wait
sufficient
for
for
a
good
implementation,
and
if
you
want
to
go
over
and
have
you
know
using
something
like
brewskis
cetera,
you
could
still
integrate
that
right.
T
The
other
thing
that
I
wanted
to
point
out
this
could
be
used,
for
example,
so-
and
we
talked
about
this
this
morning,
when
you
have
DPP,
for
example,
they
approach
that
they're
using
for
the
personal
use
in
the
in
the
in
the
buffet
to
be
transported
over
the
enterprise,
so
we're
over
eeep
by
encapsulating
the
DPP
packets
on
the
EP.
So
you
could
potentially
use
DPP
also
in
threep.
T
V
I'm
working
on
at
our
networking,
Center
in
Bremen
and
I
am
dealing
with
eduroam
and
one
experience
I
had
when
dealing
with
eduroam
is
that
the
certificate
checks
on
supplicants
in
eap-tls
are
known
to
be
faulty
and
with
faulty
I
mean
not
badly
implemented,
but
they
don't
really
happen
in
a
way
that
we
should
well
that
they
should
happen,
so
they
use
very
unsecure
defaults.
For
example,
in
android
devices
there
was
not
really
default
for
checking
with
Android
versions,
at
least
prior
to
version
7
I'm,
not
quite
sure
about
that.
V
So
the
certificate
checking
was
disabled
by
default.
Current
androids
have
this
option
used
system
certificates
with
domain
input
and
not
really
a
documentation.
What
this
domain
should
be
Windows,
Mac,
OS
iOS,
they
question
the
user
for
the
certificate
and
at
least
for
Windows.
You
just
see
a
fingerprint
and
no
information
about
the
common
name
or
the
issuer,
so
that
is
a
big
issue
in
eduroam
in
bremen,
at
least.
So.
The
reason
for
that
is
from
my
perspective
that
the
eap-tls
specification
lacks
a
specific
method
or
specific
data
to
determine
if
the
certificate
is
valid.
V
So
if
you
can
go
to
the
next
slide,
my
proposed
solution
for
that
is
to
add
a
new
certificate
extension
that
explicitly
defines
a
valid
realm
for
this
certificate,
for
which
EAP
realm
this
certificate
should
be
used.
This
is
a
big
advantage,
because
the
user
name
is
implicitly
known
from
communication
context,
and
the
realm
can
be
extracted
from
that
and
Cas
can
validate
this
if
the
realm
is
a
dns
name
and
especially
in
AD
Rome.
V
V
So
this
is
one
idea
that
was
very
like
the
first
response
that
I'm
redoing
this
work
here.
From
my
perspective,
this
could
be
a
solution
to
also
use
that
for
eap-tls,
but
I.
Don't
think
this
is
a
good
idea
to
just
simply
reuse
that,
because
it
is
not
the
same
scope,
another
idea
would
be
to
specify
a
specific
prefix
for
the
subject:
alt
name
DNS
name
or
even
for
common
name
in
the
certificate,
for
example,
eap-tls
dot,
uni-
Bremen
dot
de
for
the
Union
bremond
of
the
e
realm.
V
V
C
This
is
Elliot
again
young
Frederick,
thanks
for
the
draft
I
think
this
guy
is
a
little
bit
too.
The
work
that
Owens
doing,
if
I
understand
correctly
in
in
terms
of
realm
identification,
I
think
Owen
you're
gonna
talk
to
that.
Is
that
right
later
or
maybe
not
in
this
room
but
I
think
it
we
we
we
have.
We
have
looked
at
at
similar
issues
in
terms
similar
aspects
that
I
think
relate
a
little
bit
to
your
acne
work
and
and
and
so
I
think
they're
they're,
a
couple
of
things
that
are
hiding
out
there.
C
What
I
was
going
to
say
is
I
was
a
little
unclear.
The
use
case,
though,
in
terms
of
when,
when
you
need
that
realm
and
the
edger
in
it
available
in
edge
room,
for
instance,
in
certificate,
is
being
presented
inappropriately
elsewhere
or
they're,
not
being
able
to
select
the
certificate
for
Fred
roams
use
in
a
context
of
the
Federation.
V
So
the
the
the
main
problem
with
a
certificate
checking
is
that
it
is
quite
common
or
was
quite
common
for
a
lot
of
a
long
time
that
users
just
typed
in
their
username
and
password
and
did
not
select
any
certificate
attributes,
and
especially
with
the
user
interface
in
Eddy
row
in
Android.
This
was
the
easiest
way
and
my
aim
is
to
help
to
get
a
secure
default.
That
supplicants
know
exactly
from
the
certificate
that
this
is
valid
for
the
intended
years.
J
So
this
is
Owen
just
to
clarify
what
I
was
talking
about.
What
I'm
going
to
talk
about
in
five
minutes.
Time
is
the
other
side
of
the
house,
which
is
how
vacuum
can
be
used
to
issue
inside
certs,
but
this
is
more
relevant
for
as
Brisky
cloud,
but
it's
going
to
come
up
with
a
animal
it
around
the
week,
which
is
and
when
a
cloud
registrar
redirects
an
entity
to
a
triple-a.
How
does
the
entity
verified
the
triplicity
by
dentistry.
G
We're
not
about
Microsoft,
so
I
have
a
question
about
how
you
intend
this
to
be
used.
Is
the
idea
that
you
don't
feel
that
the
users
should
be
prompted
to
ok
the
certificate
and
that
should
somehow
automatically
check
the
NAI
against
this
nai
realm
and
just
allow
it
is
that
the
idea?
Definitely
yes,
yeah
I,
guess
I,
don't
know
it
seems
like
a
very
dangerous
thing,
because
what
prevents
you
have
assert
to
claim
any
ni
realm
right.
G
They
did
it
like
I,
my
corporation
I'll
I'll
claim
I
have
only
ni
realm
for
whatever
I
don't
actually
own.
It
has
no
relationship
to
the
cert
and
now
you're
not
putting
out
the
dialog
box.
So
I'm
can
basically
infect
the
user
system
with
a
with
a
false
nai
realm
claim
right.
I
can
I
can
put
whatever
I
want
in
there
like
I'm
Joe
blows
fish
shop
and
I'll
claim.
You
know
that
I
own
the
NIR
realm,
for
you
know
and
I,
say
the
u.s.
gov
right
and
and
you'll
accept.
V
Well,
basically,
the
idea
is
because
in
eduroam
we
deal
with
public
CAS,
public
trust
and
CAS
a
lot
to
help
to
have
this
certificate
attribute
also
verified
by
trusted
CAS,
so
that,
of
course,
if,
if
I
have
control
over
uni-
bremond
op
de
then
I
should
be
the
only
one
who
is
allowed
to
be
issued
a
certificate
with
the
humanitarian
de
realm.
I
guess.
S
It's
really
hard
to
reason
about
security,
and
one
observation
is
that
it
really
helps
to
be
able
to
build
your
production
system
out
in
such
a
way
that
it
rejects
a
larger
part
of
the
broken
ancestors
that
are
not
only
broken
but
also
misconfigured.
So
that's
maybe
a
slightly
different
objective
that
we
have
in
mind
here.
Then
you
are
usually
working
with.
D
M
So
to
address
Bernards
point
that
that's
certainly
true
but
I.
Think
one
of
the
issues
now
is
the
supplicants
by
default.
Don't
trust
any
of
the
root
CAS
for
epls
authentication.
They
do
trust
it
for
HTTPS,
and
one
of
the
issues
is
that
all
of
the
ETLs
server
certificates
have
this
TLS
web
server,
o
ID
and
I
think
it
would
help
if
the
CAS
would
issue
certificates
specifically
for
ETLs,
at
which
point
the
supplicants
could
default,
trust
all
the
route
CAS
and
then
validate
that
that
certificate
coming
over
ETLs
is
actually
an
e
TLS
certificate.
M
A
J
There
barso
I'll
be
really
quick,
so
the
problem
that,
via
an
Cisco,
trying
to
solve
contacts
light,
and
so
what
this
describes
is
it's
a
mechanism
by
which
we
can
use
acne
for
integrated
with
multiple
different
protocols
that
are
used
for
issuing
device
and
client-side
certs
next,
so
the
doc
describes
multiple
different
use
cases
how
I
can
become
integrated
with
est,
with
brewski
with
the
new
brisket
club
registrar,
but
for
parts
of
most
important.
So
this
room
is
how
it
competes,
grater,
with
teeth
and
with
tea.
J
Brisky
are
what's
been
rebranded
as
t
pop
dated
extensions
for
bootstrapping
and
I
think
that
acne
actually
requires
the
extensions.
The
new
TVs
that
have
been
defined
and
the
T
pop
dish,
and
so
I
don't
think
that
I
can
will
cleanly
integrate
with
teeth.
There's
a
couple
of
problems
with
teeth,
as
it
currently
stands,
next
slide,
and
so
what's
changed
last
presented
this
so
for
acne
integrations
used
to
cover
exactly
four
subdomains
as
well.
That
has
been
broken
out
based
on
feedback
at
the
acne
working
group.
J
J
Elliott
has
a
retry
after
TLV
and
we
try
after
two.
They
will
be
really
really
useful
when
and
the
t
p--
server
once,
which
were
searched
to
the
client
but
was
not
willing
to
do
it.
Yet
it
can't
do
it
yet
yeah.
So
next
slide
and
it's
what
its
core,
but
like
the
dystrophy.
It
should
only
be
informational.
It
doesn't
require
any
changes
to
acne.
It
will
not
require
any
changes,
es
T
or
T
RT
Popish.
J
What
is
T
and
T
two
is
used
to
antique
define
and
product
by
which
the
client
can
interact
with
the
server,
but
it
doesn't
specify
had
to
serve
interests
with
the
backend
CA
and
Acme
can
be
used
to
integrate
at
the
backend
CA
next
slide.
I
was
just
over
you
to
flow,
so
this
is.
This
is
boilerplate
Acme.
This
is
how
you
can
use
acne
to
M.
Do
the
main
claim
using
DNS
next
slide.
This
just
bought
skip
over
this?
That's
just
standard
Tipton
establishment.
J
This
is
where
it
gets
interesting,
and
so
this
is
standard
teak,
but
doesn't
have
the
Nu
T
of
these
that
have
been
defined
in
tip
update
and
the
client
sends
in
a
PK.
C
is
10
requests
to
the
tip
server.
Keep
server
then
turns
around
and
sends
a
Acme
new
order
request,
followed
by
an
acme
finalized
request,
fun
la
followed
by
the
Acme
certificate
request.
Again,
everything
on
the
left
hand,
side
the
standard,
T
everything
on
the
right
hand,
side
for
standard
Acme,
no
genius.
J
Why
the
protocol-
and
it
ends
up
with
them
the
client
even
issued
a
certificate
that
is
sent
by
the
cheap
server
using
the
pkc
as
ten
people.
Sorry,
a
PK
c
is
seven
till
the
two.
The
pledge
next
slide.
So
the
next
slide
covers
it's.
It's
the
new
T
of
these
that
have
been
defined
in
the
T
pop
date.
It
defines
what
happens
and
how
our
client
Lee
were
just
using
utilities.
So
first
is
the
client
doesn't
know
what
attributes
to
include
in
the
C
user
request,
so
the
client
sends
and
you
teach.
J
These
are
attributes
request
to
the
Steep
server.
That's
response
so,
for
example,
that
could
include
specific
information
on
what
subject
to
include
or
hots
and
to
include
and
the
client.
Then
in
step
3
sends
pikas.
He
is
10
T
of
e
to
the
t.
Server
keep
server
turns
around
and
interacts
react
me.
Acme
will
turn
around
and
say
the
status
is
processing
I'm
not
ready
to.
She
was
searched
yet
Holly.
She
was
hurt
in
a
certain
period
of
time.
Acme
has
a
mechanism
for
specifying
our
retry
after
interval
to
the
Acme
client.
J
The
teep
server
is
jack
me
client
and
turned
around
and
used
the
new
retry
after
kill
the
send
that
retry
back
to
the
client.
The
client
will
then
retry
after
that.
Timeout
has
courage,
I'm
the
way
that
the
tip
of
the
attractor
is
currently
specified.
It's
just
two
different
mechanisms
for
doing
to
retry.
One
is
wood
in
the
tunnel.
J
If
it's
a
short
control
to
is
outside
the
tunnel,
it
was
a
long
interval
and
that's
indicated
via
either
a
1x
X
or
a
2x
X
error
code
until
V
and
T
TLV
and
and
then
finally,
after
the
retry
declined.
Part
illustrator
here
is
happening
inside
the
same
tunnel.
The
client
in
step
nine
sends
the
exact
same
pkc
as
ten
requests
again
to
the
teep.
Server.
Keep
server
then
goes
to
Acme
and
the
finalize
our
ger
is
ready.
It
downloads,
the
certain
returns
it
to
the
client
in
the
pkcs7.
J
Next
slide
is
the
final
slide.
So
discussion
of,
what's
missing
from
the
draft
is
security
considerations.
It's
security
considerations
need
to
touch
on
all
the
integrations
so
EST
and
brewski
and
acme
and
t
p--,
and
but
the
biggest
the
biggest
thing
that
I'd
like
to
discuss
here
and
the
questions
I'd
like
to
get
feedback
from
is
because
this
spans
multiple
working
groups,
Acme
anima
mu.
Why
do
we
do
with
this?
Where
do
we
go
next
with
this?
With
this
draft,
several
people
on
several
organizations
have
expressed
interest
in
us,
but
we
don't
over
at
lands.
T
Sir,
not
really
on
this
point,
some
other
point,
a
just
a
clarification
question
when
you
do
the
the
translation
between
the
two
protocols,
how
do
you
handle
the
account
management
that
is
in
Acme?
So
is
the
account
that
is
used
to
request
the
certificates
from
the
temporary
server
or
from
the
client?
Well,.
P
Roman
so
back
to
the
kind
of
the
question:
where
do
we
do
it?
Unfortunately,
I
know
the
sec
dispatch
agenda
is
full,
so
we
can't
take
it
there
or
kind
of
later
this
week.
So
we
can
start
I'm.
Sorry,
there
is
still
that
you're
right,
then
yeah.
The
question
I
was
gonna,
ask
is
I
mean.
Would
this
working
group
be
against
doing
the
work
here
and
we
can
ask
you
know
acne
as
well.
U
J
J
Brewskis
loosened
up
for
ESG,
so
the
actual
certain
role
mechanism
in
brewski
just
uses
boilerplate
est.
Yes,
and
this
can
integrate
with
est
and
that
when
the
client
sends
the
est
simple,
enroll
or
foreign
oil
message
to
the
each
server.
Deep
server
can
turn
around
and
turned
it
into
an
acne
request.
Because.
J
U
J
U
A
Yeah
I
think
you
know
we
can
do
a
poll
here.
I,
don't
know
if
that's
gonna
think
how
many
people
have
read
the
document.
Okay,
three
people
so
I
think
we
have
to
get
a
little
more.
You
know
people
looking
at
it
and
you
know
if
there
is
interest
I,
don't
I,
don't
think
it's
impossible
to
do
it
in
this
working
group.
It
doesn't
strike
me
as
necessarily
being
the
most
logical
group
to
do
it
in,
but
you
know
it
I
suppose
it's
as
good
as
any
so.
J
C
Only
reason
I
think
this
le
the
only
reason
I
think
you
should
be
adopted
here
is
that
it's
gonna
normally
block
on
the
teep
update.
It's
gonna
normatively
block
on
the
t
pub
meet
so
I
mean
it
works
happening
here.
If
you're
gonna
normally
block
normatively
block
on
something
you
hacked
me,
then
then
it's
a
710
split.