►
From YouTube: IETF-RADEXT-20230522-1400
Description
RADEXT meeting session at IETF
2023/05/22 1400
https://datatracker.ietf.org/meeting//proceedings/
A
A
Good
time
of
day,
for
me
it's
evening
for
somebody
it's
morning
and
somebody
today
and
I'm
Valerie,
Smith
love
and
my
coach
is
Margaret
Collin
and
we
are
going
to
discuss
drafts
that
were
adopted,
adopted
as
a
working
group
documents
and
also
a
few
and
dropped
a
couple
of
drugs
that
are
candidates
for
adoption.
So,
let's
start
so
first.
This
is
a
note,
12
and
I.
Think
all
of
you
know
this
very
well,
but
it's
another
time
to
read
it
if
you
forgot.
A
A
B
A
A
A
C
A
F
A
A
C
A
C
Okay,
I
think,
is
everybody.
On
the
call
probably
already
knows,
we
adopted
three
working
groups
working
group
documents
since
ietf
116.,
the
TLS
document,
which
we'll
talk
about
extensively
today,
the
radius
version
1.1
document
which
we
used
to
refer
to
as
the
alpn
extensions
and
the
radius
and
TLS
psk
document.
C
C
So
that's
that's
our
status
today
and
we're
moving
along
in
schedule
as
far
as
I
know,
but
we
want.
We
do
want
to
try
to
get
the
other
documents
for
our
work
items
adopted
and
the
other
thing
that
we're
going
to
talk
about
today.
That's
not
not
on
this
slide
is
when
we
want
our
next
meeting
to
be
whether
we
want
to
have
another
interim
in
June
before
the
ietf
meeting
in
Late
July
or
not
so
be
thinking
about
that,
because
we'll
have
a
discussion
on
that
at
the
end.
C
A
A
C
C
H
C
A
I
F
I
Currently,
this
means
that
there's
a
down
reference
to
a
6x13
which
is
experimental,
and
if
we
want
to
move
radius
dtls
to
proposed
standard,
it
would
require
a
separate
rc7360
piece
document
coming
from
that
I've
looked
at
all
these
three
documents:
6613
6614
and
7360
and
I-
found
some
interesting
things
that
I
want
to
run
by
the
working
group.
I
have
run
some
of
them
via
the
working
group
in
our
Yokohama
meeting,
but
this
is
more
in
depth.
So
next
slide.
I
The
Cur,
the
first
question
is:
if
we
want
to
merge,
6613
and
6614,
or
why
I
think
it
is
good
to
merge
them.
It's
basically
6613
radius
over
TCP
includes
some
or
a
lot
depending
on
how
you
read
it
specification
for
radius
TLS
radius.
Tls
is
repeatedly
mentioned
in
the
specification
of
6613.
For
example,
there
is
a
specific
Watchdog
mechanism
proposed
in
section
2
4
of
6613.
I
I
The
comment
from
Ellen
to
just
ignore
6613,
yes,
6613
itself
could
be
dropped,
but
6614
is
based
onto
on
some
details
on
6613,
so
especially
the
connection
handling
mechanisms.
What
to
do
when
the
TCP
connection
is
closed.
So
these
things
that
are
relevant
to
our
radius
over
TLS,
although
radius
over
TCP,
is
deprecated
anyway.
I
67360
is
radius
over
dtls,
so
the
the
radius
dtls
RFC
is
basically
read.
This
document
apply
these
patches.
Then
you
have
dtls,
so
it
would
be
worth
a
thought
to
just
merge.
These
two
documents
have
truly
identical
spec
for
TLS,
because
probably
it's
easier
to
just
write
it
down
once
than
to
write
it
down
two
times
or
to
reference
it
and
say,
but
these
things
you
have
to
do
differently
and
you
don't
need
to
open
two
documents
to
apply
the
diff.
I
I
I
My
personal
opinion.
It
has
a
smell,
but
should
not
be
a
problem
per
se
at
merging
6614
and
7360.
So
TLS
and
ttls
would
need
some
additional
specification
in
the
in
the
document,
for
example,
that
what
could
be
a
problem
is
Canon
implementation
call
itself
compliant
to
the
new
RFC
if
it
implements
only
one
of
TLS
or
dtls,
that's
something
that
we
would
need
to
discuss.
I
Of
course,
the
spec
would
be
longer
so,
instead
of
having
one
document
that
specifies
exactly
what
you
need
to
implement,
if
you
only
want
to
implement
radius
TLS,
then
you
have
to
read
a
document
that
has
a
lot
of
black
paper
on
dtls
that
you
don't
really
need.
Also.
We
have
few
difference
regarding
implementation
and
security
considerations,
so
it
would
be
a
longer
document
with
some
sections
not
applying
to
the
current
protocol.
You
want
to
implement
if
you
want
to
implement
only
one
of
them
yeah.
I
So
these
are
the
downsides
that
I
thought
of
in
the
few
minutes
that
I
had
to
prepare
the
slides
so
on
the
next
slide.
I
have
now
I
have
the
options.
Yes,
sorry,
I
I
did
not
really
memorize
my
slides
quite
hard
so
that
the
the
four
options
we
have
from
my
point
of
view
is
first
to
leave
RFC
6614bs,
as
is
so
we
downrived
to
the
experimental
6613.
F
I
I
I
I
C
So
we
have
multiple
choices
here
and
I
think
it's
important
that
we
see
if
we
can
reach
some
consensus
as
a
group
for
what
we
want
to
do
going
forward.
So
why
don't
we
throw
open
the
floor
to
discussion,
I
think
I'm,
trying
to
figure
out
if
I
can
explain
to
you
how
to
raise
your
hand,
but
if
I
could
figure
out
how
to
raise
my
hand,
I
could
explain
that
so
hold
on
a
second,
while
I
try
to
figure
that
out.
C
H
I
yeah
I
I
much
as
I
hate,
enormous
documents,
I
I,
do
think
in
Frederick's
right
here.
Merging
all
three
is
likely
the
best
that
way
we
can
have.
You
know
perhaps
a
section
about
connection
issues,
a
connection,
a
section
about
TLS
and
then
a
little
bit
different
sections
on
TLS
versus
dtls,
some
of
the
feedback
recently
from
the
TLs
people,
or
that
dtls
really
should
be
pronounced
TLS
and
we
just
call
it
all
the
same
thing
given
given
the
overlap
between
the
documents.
I
I
think
it
may
be
useful.
C
Speaking
for
my
myself,
my
own
opinion,
I
I,
could
see
it
going
either
way.
One
thing
that
wasn't
listed
in
in
John
Fred's
reasoning
was
it
that
makes
me
say:
leave
it
separate
is
that
we
need
to
make
smaller
changes
to
the
document.
It
would
be
more
of
a
minimal
changes
thing.
I,
I,
don't
object,
I
kind
of
think
Beyond
Fred
should
get
to
the
side
since
he's
editing
it
and
I
don't
object
to
merging
them
into
one
document.
C
I
think
when
we
do
that,
we
have
to
be
careful
to
do
two
things.
One
is
that
it
is
possible
to
have
separately
be
able
to
claim
your
compliance
for
the
two
separately.
If
we're
very
clear
in
the
document
where
all
the
must
and
shoulds
are
and
stuff
what
they
apply
to,
you
know
we
could
say
if
they
don't
say
they
apply
to
both
and
if
they
only
apply
to
one,
it
will
be
made
explicit
so
that
you
can
say
which
one
you
implement.
C
That
would
require
a
little
work,
though
I
think,
to
make
that
as
clear
as
possible.
Also,
we
need
to
not
have
I
think.
While
we
have
the
hood
off
mentality,
because
there
are
quite
a
few
implementations
at
least
of
radius,
TLS
and
I-
don't
think
we
want
to
invalidate
any
of
them,
and
so
we
want
to
be,
and
I
and
I
realize,
there's
even
a
little
ambiguity
about
what
they
Implement,
because
do
they
only
implement
66
14
or
do
they
also
Implement
the
stuff?
C
In
the
you
know,
the
the
diffs
that
are
elsewhere,
but
I
I
think
we
just
want
to
be
careful
when
we're
doing
this,
not
to
turn
it
into
an
overhaul
of
how
radius
works
with
TLS
and
dtls,
but
I
think
we
we
you
know
just
making
an
one
document,
opens
up
more
possibility
of
of
losing
sight
of
that.
I
think
we
would
need
to
be
careful
to
keep
side
of
it,
but
I
don't
have
any
objection
to
merging
them.
As
long
as
we
keep
those
two
things
in
mind:
okay,
a
Valerie.
A
Can,
as
participant
with
no
heads
I,
think
that
the
first
option
is
really
attractive,
because
the
TLs
and
dtls
has
a
lot
of
overlap
and
with
about
six
six
one,
three
I
think
it's
what
a
little
stuff
that
is
relevant
as
far
as
I
understand
it's
which
took
and
something
like
this.
So
probably
imagine
all
these
three
documents
into
one
is
a
good
idea,
and
I
also
want
to
speak
to
to
really.
F
A
D
F
D
I
agree
with
what
basically
Alan
and
you
Valerie
just
said,
also
observing
that
the
differences
between
TLS
and
dtls
are
intentionally
kept
at
the
minimum,
and
so
that
kind
of
suggests
that
it
would
be
a
good
idea
to
treat
them
in
in
one
go.
But
potentially,
as
Ellen
suggested
in
just
pointing
out
the
different
section
and
taking
into
account
that
someone,
a
company
implementing
a
stack,
wants
to
indicate
compliance
to
TLS
or
ddls
or
potentially,
both
so
I.
Think
that
should
be
accomplishable
without
a
huge
effort.
B
B
I
think
the
existing
documents
we've
got
maybe
are
good
for
people
who
have
existing
implementations
and
want
to
bring
them
up
to
scratch,
but
definitely
a
kind
of
unified
document
that
has
everything
bundled
into
ones
like
this
is
what
you've
got
to
do
is
useful
to
someone
trying
to
build
this
so
I
I'm
in
support
of
it
I
think
it's
going
to
be
a
bit
more
work
and
we'll
just
have
to
come
up
with
something
to
help
and
Implement
to
drag
them
through
clicking
and
screaming.
To
do
the
right
thing.
I
C
J
J
That
I've
seen
is
also
that
there
are
certain
platforms
where,
for
example,
ttls
may
not
be
available
Sunday
on
those
platforms,
one
could
only
implement
the
radio,
solar,
TLS
and
TCP,
so
one
spec
would
be
good,
but
it
would
be
also
good
that
it
would
be
possible
to
say
that.
Okay,
the
implementation
is
complement
with
the
new
specification,
but
it
only
implements,
for
example,
the
TCP
version
of
it.
C
A
C
A
H
C
I
No,
no
I
think
that's
good
I
I
have
first
step.
I
have
made
first
steps
for
the
new
document
already
so
I
I
now
I
can
fully
commit
to
to
this
and
I
I.
Don't
think
that
someone
on
the
lists
will
raise
an
objection,
but
if
so,
then,
of
course
that
would
be
okay,
but
now
I
can
start
with
a
new
document
and
I
will
have
an
update.
Then.
H
This
is
a
quick
review
of
how
alpn
Works
the
client
connects
over
TLS
to
the
server
and
sends
a
Alp
and
TLS
header
field.
Saying
quote
radius
one
one
and
the
server
either
replies
with
nothing
or
Echoes
it
back.
Alpn
has
Provisions
for
sending
multiple
names
from
the
client,
but
that's
it
once
that
TLS
connection
is
established.
Then
you
get
access,
requests
and
access
reply
or
access
accept
sorry
as
normal
in
the
TLs
connection.
H
If
either
end
does
not
send
this
radius
one
one
string,
then
it
falls
back
to
6x14,
so
it's
completely
compatible,
which
is
nice
in
terms
of
making
things
easier
for
the
end
user
rather
than
having
every
vendor
come
up
with
their
own
thing.
For
how
to
configure
this
there's
a
suggested
flag
to
either
forbid,
allow
or
require
it,
and
this
actually
helps
with
the
negotiation,
because
it's
difficult
to
describe
what
to
do
when
you
receive
this
string
unless
there's
a
flag
which
says
what
you
do
when
you
receive
the
string.
H
The
code
and
length
fields
are
unchanged
in
the
packet
header
based
on
feedback
from
the
list.
The
identifiers
is
reserved
and
replaced
with
a
token.
The
authenticator
field
is
four
octet
token,
just
like
diameter
and
12
octets
reserved,
and
this
allows
for
232
packets
per
connection,
which
solves
a
long-standing
issue
with
radius
next
slide.
H
All
of
the
obfuscated
attributes
are
encoded
as
their
underlying
data.
There
is
some
caveats
around
stuff,
like
user
password,
it
has
a
maximum
length
limitation
and
message.
Authenticator
among
a
few
other
ones
are
ignored,
Chap
and
Ms
chap
those
were
never
dealt
with
by
proxies,
they
were
just
opaque
blobs
that
were
copied
back
and
forth.
H
H
So,
based
on
questions
on
the
list,
there's
some
questions
about
authentication
methods.
All
the
authentication
methods
are
entirely
unaffected.
The
transport
does
not
affect
the
authentication
right,
so
radius
goes
over
UDP
TCP,
TLS
dtls.
It's
all
fine.
The
proxies
use
md5
to
encrypt
and
decrypt
stuff,
like
user
password,
but
the
actual
data
is
unchanged
from
end
to
end
across
multiple
hops.
H
The
benefit
now
about
this
is:
if
some
site
wants
to
do
the
full
security
checklist,
they
can
drop
chap
an
MS
chat
locally
and
use
something
else
like
epls
and
then
their
security
people
can
look
at
the
operating
system
and
go
yes.
Md5
md4
do
not
exist
on
the
operating
system
at
all.
Therefore,
it
stiffs
compliant.
H
This
is
a
little
stronger
than
what
fips
actually
requires.
Fips
just
requires
that
you
don't
depend
on
these
things
for
security
which
radius
doesn't,
but
the
number
one
way
that
people
understand
fits
and
the
easiest
way
to
ensure
you're
implementing.
It
is
just
to
ban
things
like
md4
and
md5
entirely,
because
it's
it's
too
hard
to
ask
the
average
administrator
or
the
average
company
to
audit
an
OS.
Do
you
see
whether
or
not
the
uses
of
md4
and
md5
fall
within
the
allowed
uses
in
fips?
It's
just
easier
to
ban
it
next
slide.
H
So
this
is
implemented,
it's
not
enabled
in
the
default
build
because
we
don't
want
to
break
things
by
default.
On
the
other
hand,
if
people
want
to
do
interoperability
testing,
they
can
build
it
with
a
special
flag,
poke
at
the
configuration
a
bit
and
get
it
working
in
the
end.
The
diff
is
very,
very
small,
which
leads
me
to
conclude.
We
probably
should
have
done
this
originally
with
dtls,
but
that's
all
water
under
the
bridge.
H
So
to
address
Bernard's
comments
about
6421
in
cryptography.
This
document
now
says,
among
other
things,
that
further
cryptographic
Primitives
are
forbidden
in
radius
and
it
should
be
essentially
finishing.
The
research
started
in
6421
when
coupled
with
moving
TLS
to
standards
based
and
then
yeah,
the
one
minor
note
at
the
top.
The
negotiation
status
has
to
be
cached
for
session
resumption,
because
TLS
doesn't
do
this
for
us.
So
it's
a
bit
annoying,
but
that's
life
next
slide.
H
So
some
future
looking
thing,
considering
we're
changing
radius.
How
does
this
affect
new
standards?
And
the
answer
is
by
and
large
it
doesn't.
This
document
describes
how
to
transform
any
radius
thing
into
this
transport
profile,
so
any
new
radius
document
that
defines
attributes
that
defines
new
packets.
Whatever
look
at
this
document,
here's
how
to
transform
A
to
B
stuff
it
into
the
radius11
connection,
and
it's
all
fine
as
part
of
the
cryptographic
updates.
H
H
H
B
I
H
H
C
Our
Charter
has
us
releasing
them
at
separate
times.
I
think
there's
a
real
question
as
to
whether
the
deprecation
document
and
I
think
this
was
brought
up
on
the
list.
Shouldn't
only
follow
the
new
TLS
document
or
something,
but
the
alpn
one
goes
out
before
the
the
new
TLS
document,
according
to
our
Charter
and
and
work
yeah.
H
C
We're
just
going
to
continue
and
if
Matthew
comes
in,
he
can
call
out
to
us.
There's
been
very
little.
I
would
say
dispute
about
this
document
on
the
list
and
the
comments
are
largely
minor
and
I
would
say
friendly,
Amendment
type
of
things
or
informational
question
type
of
things,
so
I.
The
question
for
this
group
is:
are
we
ready
to
go
to
working
group
last
call
with
this
document,
or
do
people
think
that
there's
anything
significant
that
still
needs
to
be
done
before
this
document
is
done?
C
K
L
K
People
not
being
crypto
people
so
therefore
saying
it's
actually,
rather
than
trying
to
forbid
radio
forbid
crypto.
It's
trying
to
say
that
radius
experts
shouldn't
be
designing
crypto
when
I've
read
through
the
document
in
Fair
detail
a
couple
of
times
and
that's
one
thing:
it
just
stands
out.
It's
saying:
oh
you
we're
not
allowing
this
in
the
past
and
we're
not
doing
it
now,
but
we're
not
allowing
you
to
do
something
in
the
future.
K
K
Back
about
it
says:
implementations
must
support
tlspsk
and
I
think
the
answer
came
back
so
that
would
be
removed
and
it's
still
in
the
latest
draft,
but
I
didn't
know
whether
there
was
a
reason
for
that
or
whether
that
was
actually
going
to
was
going
to
be
still
in
there.
It
just
feels
like,
if
something's
not
directly
relevant
to
the
to
this
particular
draft,
but
it's
just
my
company
comments.
H
H
Sort
of
thrown
in
there
as
part
of
a
grab
bag
of
might
not
hurt
in
terms
of
from
bidding
new
crypto,
I
I.
Think
the
move
in
the
iepr
for
the
last
couple
decades
has
been
to
move
away
from
per
application
cryptography
and
just
use
TLS
for
our
ipsec
for
almost
everything,
because
once
you
define
an
application,
specific
crypto
thing,
it
now
needs
to
be
agile
and
negotiate,
etc,
etc,
and
you
can
dump
that
in
your
protocol
you
can
just
throw
your
hands
up
in
the
air
and
go
yeah.
H
H
C
H
H
J
H
If
no
one
finds
it
useful
right,
then
then
I
guess
you
know
it
might
as
well,
not
not
be
there.
The
reason
for
me
putting
some
of
those
flags
into
the
packets
would
be
it
might
make
sense,
especially
in
a
multi-hop
proxy
environment,
to
have
some
kind
of
signaling
whether
your
transport
is
secure
or
not.
H
The
counter
argument
really
is
that
this
belongs
in
some
kind
of
routing
protocol,
where,
when
all
these
proxies
connect
to
each
other,
they
make
certain
promises
along
the
way
and
that's
less
of
a
per
packet
thing.
So
the
packets
going
back
and
forth,
don't
really
need
to
know
that
the
routing
fabric
is
secure.
The
routing
fabric
should
take
care
of
it
that
itself,
via
some
out-of-band
protocol
or
some
other
protocol.
D
Of
course
this
was
many
many
years
ago,
and
so,
while
conceptually
the
idea
of
having
Android
security
over
a
multi-hop
protocol
makes
a
lot
of
sense,
the
community,
the
blowing
diameter,
didn't
see
that
need.
So
that
was
the
reason
why
it
didn't
complete
in
the
end,
but
maybe
maybe
now
the
world
is
different.
So
so
you
never
know
things
change,
but
I
think
maybe
I
need
that.
H
C
Okay,
it
sounds
to
me
like
we
need
a
little
bit
of
clarification
in
this
document
about,
what's
meant
regarding
forbidding
further
cryptographic,
Primitives
and
maybe
there's
one
other
clarification
point,
but
there
doesn't
seem
to
be
any.
There
still
doesn't
seem
to
be
any
major
objection
to
what's
in
this
document,
so
maybe
Alan
you
want
to
spin.
It
wants
to
to
clean
those
things
up
and
then
we'll
we'll
look
at
going
to
a
Last
Call
on
the
list.
Does
that
make
sense,
yeah.
H
H
Feedback
from
the
community
has
been
that
stuff
like
psks,
would
be
useful,
because
certificates
are
hard
on
some
more
information
there
about
why
it's
hard
would
be
useful.
I
have
a
discussion
in
a
couple
weeks
with
edurome
EU
that
I'll
be
going
to.
Hopefully,
I
can
get
a
little
bit
more
information
there.
H
One
one
known
issue
with
PS
or
with
TLS
certificates
is
that
everyone
either
uses
a
private
CA,
which
has
its
own
issues
to
manage
I'll,
make
something
simpler
or
if
you
use
a
public
CA.
You
now
have
the
issues
of
you
are
lying
to
the
certification
authorities,
because
the
public
Cas
are
run
by
the
ca,
slash
browser
forum,
their
needs
are
browser,
needs
and
that's
it.
So
if
you
go
to
the
the.
D
H
So,
in
terms
of
tlspsk,
the
one
thing
which
was
sort
of
missed
in
the
previous
documents
is
that
you
can't
just
add
a
psk.
You
also
have
to
have
an
identity
previously
in
radius.
The
identity
was
the
source
IP
address
in
psk.
You
actually
have
to
give
an
explicit
identity
because,
among
other
things,
TLS
requires
it
and
your
client
may
be
behind
in
that
and
may
change
IPS,
in
which
case
you
want
to
use
the
TLs
identity
and
not
the
source
IP.
H
So
the
administration
interfaces
have
to
be
updated
to
add
both
of
these
fields
and
for
security.
The
suggestion
is,
should
not
use
the
same
shared
secret
for
radius,
UDP
and
tlspsk.
Otherwise,
there's
some
thought
that
you
could
look
at
the
radius
traffic
crack
the
secret
and
then
use
that
to
crack
the
tlspsk
sessions.
So
it's
best
to
require
that
those
are
substantially
different.
H
I
mean
if
we
go
Whole
Hog,
it
might
be
worth
adding
it
to
the
conglomerated
TLS
document,
in
which
case
it
gets
enormous
it.
It
depends
on
how
much
content
there
is.
This
is.
The
purpose
of
this
document
is
really
hey.
Not
many
people
implemented
tlspsk
because
they
didn't
know
what
the
heck
to
do
right.
You
now
have
an
identity.
Where
does
that
go?
How
do
you
configure
it,
and
so
everyone
gave
up-
and
this
is
really
a
a
documenting
of
how
to
use
this
protocol
rather
than
anything
else-
Yen
Frederick.
C
C
B
I
I
mean
I,
think
they
it's
worth
keeping
this
as
a
separate
document,
I
see
it
more
as
a
how
to
expose
how
an
implementer
really
exposes
this
to
the
user
really
and
how
they
can
almost
safely
use.
It
there's
not
really
I
think,
as
Alan
touched
on
earlier,
there's
no
meat
in
there
I
guess
like
describing
there's
no
attributes
in
there
there's
nothing
like
that.
B
M
Yeah
I
I
would
be
important
to
to
merge
it
in
the
other
document,
but
the
reason
being
that
I
anticipate
this
mode
of
credentialing
to
be
the
the
most
commonly
used,
because
you
know
for
various
reasons,
not
least
it
just.
You
know
it's
a
it's
the
analog
of
what
what
people
are
doing
today
already
with
radio
secrets
and
I
think
it's.
You
know
it's
a
familiar
model
that
people
are
comfortable
with
Etc
and
and
once
it's
implemented
in
products,
I
just
think
people
will
will
keep
using
it.
H
I
guess
for
me
the
the
point
there
I
mean
there's
certainly
value
to
having
all
this
in
the
document:
hey,
here's,
the
updated
radius,
TLS
document,
which
says
everything
there
is
value
in
that.
But
if
it's
going
to
be
implemented,
I
think
there's
there
may
be
benefit
to
implementing
it
and
Publishing
it
soon.
Rather
than
later.
H
C
So
speaking,
just
as
a
participant
I
think,
maybe
we
should
embrace
the
power
of
and
like
maybe,
we
could
fairly
quickly
publish
a
experimental
version
of
this
to
go
along
with
the
experimental
TLS
and
then
merge
them
in
when
the
6614
best
is,
you
know,
and
friends
is
actually
published.
My
concern
is
this:
there's
just
no
reason
to
tie
it
to
something:
that's
going
to
involve
it's
going
to
be
hooked
to
multiple
other
documents
and
I.
C
H
C
C
I
think
we're
going
to
get
a
lot
of
interest
in
in
radius
TLS
due
to
the
fact
that
we've
telegraphed
that
the
ietf
is
going
to
deprecate
radius,
T,
radius,
UDP,
so
I
think
that
getting
this
out
so
that
this
option
is
out
there
and
well
defined
would
be
valuable.
You
know
to
do
it
as
soon
as
possible.
So
that's
just
my
my
opinion,
though.
C
H
Document
needs
an
update.
I
will
do
that
probably
later
this
week.
My
goal
first
is
to
get
the
alpn
document
done
and
out
and
I
can
dump
that
all
out
of
my
queue
in
this
document,
I
don't
think
it's
that
complicated.
The
only
real
complexity
in
it
is
TLS
one
two
versus
TLS,
one,
three,
where
TLS
one
two
you
can
do
psk
it's
easy,
but
the
psk
is
not
tied
to
the
particular
TLS
method.
H
So
the
question
there
is:
do
we
go
yeah,
it's
probably
okay,
to
use
psk
with
tls12
and
sort
of
ignore
various
various
potential
security
issues.
Or
do
we
say
you
have
to
use
tls13,
in
which
case
there
probably
needs
to
be
a
bit
more
text
explaining
how
to
do
that.
But
yeah.
My
hope
is
Margaret
said:
is
this
document's
fairly
small?
We
can
get
it
out
soon.
C
You
know
the
security
area
to
get
someone
to
look
at
or
get
the
sector
to
to
weigh
in
on,
because
sending
them
a
document
they're
going
to
say
this
is
unsafe
and
it
can't
be
done
that
way.
It
doesn't
seem
very
useful,
so
I
don't
know
is
that
something
we
could
get
some
early
review
on
is
whether
or
not
it
would
be
okay
to
say,
use
this
with
1.2
or
whether
or
not
we
need
to
require
1.3.
In
order
for
this
to
be.
C
C
H
Well,
the
the
original
phrasing
in
the
document
was
deprecating
UDP
and
deprecating
radius
in
part
to
get
people
excited
and
actually
paying
attention
to
these
issues.
The
biggest
issue
is
that
md5
is
garbage.
At
this
point.
It's
been
cracked
given
a
radius
packet,
a
hobbyist
can
crack
all
eight
character,
shared
secrets
in
a
short
period
of
time,
and
if
someone's
willing
to
throw
money
at
it
low
millions
of
dollars,
you
can
crack
radio
shared
Secrets
going
up
to
like
10
or
12
characters.
H
The
other
issues
are
that
sensitive
data
such
as
device
information
and
personal
location,
is
sent
in
the
clear
even
with
stuff
like
mattinas,
which
is
Mac,
address.
Randomization
I
wouldn't
be
surprised
if
you
could
still
do
some
fingerprinting
on
devices.
You
know
looking
at
TLS
ciphers,
for
example,
for
epls
you
could
fingerprint
particular
devices
if
you
wanted
to.
There
are
also
issues
with
the
security
of
tunnel
password
when
sent
in
COA
packets
tunnel
password
originally
depended
on
the
random
request.
H
Authenticator
in
the
access
request
and
access
accept
CLA
packets,
the
request
authenticator
is
all
zeros,
so
there's
only
12
bits
of
entropy
protecting
the
tunnel
password.
This
has
been
raised
by
me
on
the
radius
left
many
years
ago
and
everyone
sort
of
threw
up
their
hands
and
went
well
nothing.
We
can
do
about
it
now,
but
that
is
a
serious
issue
for
anyone
sending
tunnel
passwords
over
the
net.
12
bits
of
entropy
is
enough
to
crack
them
instantly
by
anyone.
H
H
My
counter
argument
to
that
is:
there's
a
big
difference
between
one
site
deploying
ten
thousand
or
a
hundred
thousand
nasas
with
ipseac
and
something
like
Ed
your
realm.
Where
you
have
10
000
sites
interconnecting
this
document,
hopefully
should
be
standards
track.
Bernard
was
arguing
against
that
a
little
bit.
However,
we
do
have
Decades
of
experience
using
radius
over
TLS.
We
have
10
years
of
experience
so
ipsec
we
have
10
years
experience
with
radius
over
TLS,
perhaps
a
little
bit
less
experience
with
dtls,
but
I
know
some
of
the
large
equipment.
H
H
K
H
Running
a
radio
server
on
Microsoft
Windows
either
have
to
use
NPS
and
not
TLS,
or
they
have
to
investigate
alternatives
also,
historically
and
I.
Think
one
of
The
Blocking
issues
with
TLS
and
open
source
was
this
long-standing
bug
in
free
radius,
which
has
now
been
addressed,
and
so
that
should
help
make
TLS
easier
to
use
and
what
would
happen
if
the
connections
would
just
block
unmiss
made
proxies
more
unstable
than
they
should
have
been
next
slide.
C
C
What
has
to
happen?
I
think
when
we
deprecate
something
is
that
we
I
mean.
Typically,
you
write
an
info
document
and
actually
move
the
previous
standard
to
historical,
but
that's
not
what
we
want
to
do
here
in
a
way
because,
because
the
previous
standard
is
we're
still
going
to
be
counting
on
it
and
then
running
it
over
over
TLS,
so
I'm
not
sure
it
matters
whether
this
is
standards
track
or
not,
I,
don't
I,
don't
care.
The
question
is
I.
C
H
H
H
H
I
believe
there
may
be
benefit
in
terms
of
publicity,
I
I
know
people
don't
pay
a
lot
of
attention
to
experimental
versus
standards
track,
but
in
terms
of
of
marketing
and
propaganda
it
may
be
better
to
have
this
a
standard
track
so
that
you
can
point
at
it
and
go
the
standard.
Ietf
approved
way
of
doing
radius
is
secure,
and
not.
This
is
an
informational
document
saying
you
might
want
to
do
this,
but
you
really
don't
have
to
well.
C
I
mean
we
could
make
it
standard
strike
and
explicitly
make
it
update
those
documents
in
terms
of
their
applicability
and
I.
Think
that
would
be
the
way
to
do
it
strongly
right
right.
You
know,
but
I,
don't
that
isn't
the
big
issue
to
me.
The
big
issue
to
me
is
what
it
says,
obviously,
but
also
I
think
it
should
come
out
with
a
a
normative
reference
to
us.
The
standards
track,
TLS
document
yeah.
A
A
A
C
A
E
C
H
There
are
many,
many
Cloud
radius
providers
compared
to
say
10
years
ago,
pretty
much
the
bulk
of
them
that
I've
seen
just
use,
UDP
and
I
think
this
is
a
absolutely
horrific
practice
to
use
to
do
and
and
my
sort
of
offline
discussions
with
them
have
been
it
works.
We're
allowed
to
do
it
we'll
just
expose
all
of
our
users.
Information-
and
this
is
for
people
not
even
doing
Eve
right.
H
C
C
Is
that,
like
we
have
a
cloud
radius
implementation
and
we
use
a
VPN
ipsec
for
exactly
the
reason
she
just
cited
so
I
think
there
are
valid
uses
for
running
this
over
ipsec
rather
than
because
it's
not
just
it's
not
just
the
stuff
that
would
go
through
a
proxy.
You
know
it's
the
stuff
that
your
your
internal
clients
would
send.
G
C
F
F
The
only
thing
I
want
to
point
out
is
that
when
you
move
away
from
the
ipsec
to
the
rad
side
version
of
hearing
this,
you
do
lose
some
insight
when
you're
trying
to
debug
packet
by
packet
as
to
what's
going
on
and
I
think
as
we
move
the
TLs
1.3
we're
going
to
lose
a
little
further
inside,
because
the
certificate
exchange
itself
will
also
be
encrypted.
So
I
guess.
The
only
thing
I
wanted
to
point
out
is
that
I
think
it
would
be
really
helpful
for
all
radius,
vendors
and
implementers.
F
C
F
H
Has
to
go
somewhere
right,
there
has
to
be
a
suggestion
of
hey
it's
not
just
or
defining
bytes
on
the
wire
and
if
you
implement
it
or
you
try
and
administer
these
systems,
it
sucks
to
be
you
too
bad
right.
They,
they
I,
think
this
is
a
good
point.
There
really
does
need
to
be
some
tax
going
by
the
way
when
you
get
something
allow
the
administrator
to
see.
H
H
H
E
G
Yeah
thanks
Margaret
yeah,
so
I
think
we
didn't
get
time
at
in
Yokohama
to
describe
this.
This
draft
draft
zero.
So
here
we
just
got
a
couple
of
slides
talking
about
the
background.
I
know
in
particular
I
guess
from
a
charter
perspective.
We
see
this
as
out
of
Charter
and
obviously
we're
very
busy
on
all
of
the
documents
that
we've
just
been
discussing,
so
we're
recognizing
we've
got
that
issue,
but
still
we
think
we'd
like
to
to
share
this
our
ideas
and
get
some
feedback.
G
G
G
G
It
was
often
the
case
that
you
bought
a
a
silo,
a
vertical
stack
of
of
end-to-end
systems,
and
so
it
may
well
be
that
you
have
multiple
vendors
equipment
already
in
place
in
in
networks,
and
so
one
use
case
is,
is
to
be
able
to
interface
between
different
vendor
equipment.
But
obviously
the
one
that
I
think
primarily
of
interest
to
us
is
the
multi-domain
environment.
G
When,
when
we
have
one
Central
in
in
a
visited
domain
and
one
Central
in
a
home
domain,
and
so
that
then
allows
that
same
capability
as
Now,
we
move
the
bond
between
the
peripheral
and
the
AP,
and
now
we're
able
to
move
the
when
the
peripheral
becomes
visible
in
in
a
new
network
and
and
is
observed
by
a
new
AP.
We
have
the
ability
to
effectively
move
the
bond
to
an
AP
in
a
separate
domain,
so
that
should
be
I,
guess
familiar
from
a
I
guess:
North
authentication
perspective.
G
The
other
aspect,
obviously
we're
talking
about
vle,
which
is
non-ip
data,
and
so,
unlike
Wi-Fi,
when,
when
we
give
everything
an
IP
address
and
we
we
let
it
sort
itself
out
from
an
IP
perspective.
We
need
to
understand
how
to
deal
with
non-ip
data
and
in
particular,
how
peripheral
communicates
with
a
ble
application
and,
and
so
part
of
the
draft,
at
least
from
a
an
Amex
perspective,
talks
about
how
we
can
use
mqtt
to
afford
the
the
non-ip
data
between
these
different
domains.
G
So
that's
the
background
next
slide,
so
just
from
a
radius
perspective
we
need
to
so
so,
just
as
in
you
know,
if
we
have
an
Eep
exchange,
we
we
pass
credentials
and
then
we
deliver
the
Eep
msk
information
towards
the
visited
Network.
We
need
to
be
able
to
deliver
Bluetooth
keying
material
to
that
ble
Central
in
the
visited
Network,
and
so
we
have
the
access
request,
access,
accept
or
reject
to
the
radius
server,
and
we
need
that
radius
server
to
interface
into
the
ble
security
database.
G
So
so
we
assume
the
ble
Central
in
the
home
network.
If
that's
on
on
the
top
is
exposing
security
information
that
it's
been
generating
generated
as
part
of
the
bonding
process,
and
then
it
enables
access
to
that
security
information
to
a
radio
server,
which
is
then
able
to
deliver
a
key
material
to
the
ble
Central
on
the
bottom
of
the
figure,
and
then
that
that
allows
then
the
peripheral
to
move
from
the
first
access
point
to
a
second
access
point
and
re-establish
the
bond
on
the
new
access
point.
G
So
that's
I'll
touch
on
on
radius.
Next
slide,
we
talked
about
mqtt
and,
and
so,
as
we
said,
we
do
have
a
an
Annex
describing
him
qtt,
we're
discussing
where
the
correct
home
for
for
this
is
with
an
ITF
and
so
likely
that
this
will
move
out
of
this
draft
and
and
emerge
in
a
different
deliverable
and
talking
about
sort
of
iot
operations
about
how
to
do
standardize.
G
Those
interfaces
between
ble
here,
but
also
thinking
more
broadly,
around
zigbee
and
other
low-powered
devices
that
that,
how
can
we
standardize
the
interface
to
allow
these
sort
of
row
into
domain
roaming
interfaces
to
be
realized?
And
as
we
said
so,
the
intent
is
to
publish
that
in
a
separate
deliverable.
G
Next
slide,
so
obviously
we
don't
have
Eep
and
and
what
we
do
from
a
security
perspective
is
that
we
assume
operation
of
of
Bluetooth,
privacy
and
and
Bluetooth
privacy.
There
is
various
there's,
an
identity,
resolving
key
which
is
used
by
both
the
peripheral
and
the
central,
an
exchange
during
the
bonding
procedure,
so
so
leveraging
we're
not
looking
to
change
the
Bluetooth
protocol
at
all,
but
using
Bluetooth
privacy.
G
G
So
the
idea
is
to
use
exactly
the
same
approach
from
a
radius
perspective,
so
using
the
the
prand
in
the
username
attribute
and
the
hash
in
a
password
attribute
one
of
the
comments
from
from
Josh
an
interesting
talking
about
the
md5
discussion
earlier.
What
was
how
little
we've
only
got
24
bits
of
entropy
from
a
hash
perspective
and
obviously
sorry.
G
Yeah,
so
we've
only
got
24
bits
from
a
hash
perspective,
and
how
do
we
protect
that?
And
so
that's
one
of
the
issues
that
we
currently
have
this
did
to
address.
But
the
idea
is
that
we
pass
the
peer
under
the
hash
over
radius
and
the
access
request
and
the
radius
server
is
then
able
to
do
the
the
corresponding
match
of
P
runs
against
its
known
irks
and
hashes
to
understand
whether
this
peripheral
is
is
then
known.
G
So
that's
I,
guess
some
background
to
the
next
slide,
just
very
quickly
on
the
radius
profile
yeah.
So
in
this
is
the
draft
zero
zero.
So
so
we
think
we
need
a
new
attribute
type
for
nasport
type
for
to
identify
a
wireless
Bluetooth,
low
energy
and
then
we're
proposing
some
new
attributes
get
service
profile
is
is
linked
to
attributes
in
the
Bluetooth
advertisement,
and
so
these
may
be
interesting
to
signal
over
a
radius.
G
The
ble
King
material,
we
obviously,
as
we
said,
we
need
to
be
able
to
deliver
that
from
the
server
over
to
the
nas
and
then
the
other
attributes
are
linked
with
the
establishment
of
the
mqtt
signaling
between
the
ble
Central
and
the
mqtt
broker.
So
a
broker
URI-
and
we
assume
you
know
websocket,
secure
signaling
of
mqtt,
because
we
Face
the
same
issue
as
as
Alan
faces
from
a
I
guess,
a
Nat
Gateway
perspective
and
being
able
to
transition
over
a
Nat
Gateway.
G
G
Those
are
being
worked
through,
in
particular
the
the
it's
interesting
on
the
topic.
Around
new
new
cryptographic
constructs
that
we
had
in
the
previous
draft,
and
so
obviously
we
need
to
be
able
to
deliver
the
Bluetooth
key
material,
and
how
do
we
protect
that?
Keying
material
is
one
of
the
issues
that
we
face
as
it
relates
to
this
draft,
but
you
can
see
there
in
terms
of
the
iot
onboarding.
It's
then
there's
a
a
branch
called
issues,
April
23,
which
we're
working
through
the
issues
being
identified.
H
H
H
H
G
Thanks
yeah,
so
so
Point
second
in
terms
of
yeah,
this
this
attribute
isn't
isn't
used
whatever
and
so
so
yeah,
that's
certainly
will
be
addressed,
I
guess
the
key,
the
key
material.
Obviously
it's
defined
within
the
Bluetooth
standard,
but
but
perhaps
was
never
imagined
that
it
would
then
be
exposed
to
third-party
systems,
and
so
that's
one
of
the
challenges.
I
guess
we
face
I
agree
from
a
server
perspective.
It's
it's
it's
it's
a
blob,
opaque
blob
and
perhaps
then
doesn't
require
to
be
expanded
further
and
I.
G
Guess
that's
one
of
the
issues
that
we
need
to
work
through
about.
You
know
how
how
best
to
address
that
issue,
but
it
would
have
been
nice
to
be
able
to
reference.
You
know
some
of
those
parts
of
the
specification,
but
obviously
that
doesn't
exist
from
a
Bluetooth
specification
perspective,
because
that
was
never
the
intent,
I
guess
when
they.
When
that
you
find
these
in
terms
of
the
hashing
yeah
I,
guess,
we've
we've
done
some
sums
and
you're
right.
This
is
interesting.
G
Just
I
mean
even
just
from
a
single
Enterprise
perspective
about
how
do
you
optimize
your
your
hashing?
And
how
do
you
look
at
your
candidates?
Yeah?
There
is
certainly
optimizations
there,
but
I
guess.
This
is
one
of
the
costs
of
of
reusing
the
identity,
resolving
key
in
these
mobile
deployments,
but
yeah
I
think
we're
aware
of
the
cost
of
hashing
and
and
how
that
can
be
optimized
and
finally,
on
the
mppe
and
the
existing
eat.
C
C
G
G
C
G
Yeah,
so
this
is
just
for
the
to
calculate
the
the
Privacy
address.
That's
all
we're
doing
in
terms
of
the
addressing,
and
so
it's
it's
a
it's
a
valid
security
concern
in
terms
of
being
able
to
take
a
private
address
that
you
see
on
the
wire
and
then
re-transmit
a
Bluetooth
advertisement
with
the
same
private
address.
But
but
that's
the
Privacy
aspect.
G
C
C
C
The
document
I
think
at
this
point
we're
just
being
asked
to
look
at
the
document.
I,
don't
know,
I
think
it's
up
to
Paul
and
others
to
tell
us.
If
they
decide
we
would
be
a
potential
home
for
this
document.
At
this
point,
the
only
thing
I
know
of
that
we've
been
asked
to
do
is
is
review
the
document.
So
next
topic
up
on
the
agenda
is:
when
do
we
meet
next?
C
We
are
obviously
planning
to
meet
I
hope.
It's
obvious
at
ietf,
I
think
it'll
be
117
in
San
Francisco
in
the
last
week
of
July.
But
do
we
want
to
have
another
interim
meeting
in
somewhere
in
the
middle
of
June
to
progress
these
documents
and
I
will
encourage
the
document
authors
to
say
whether
or
not
that
will
be
useful
and
other
people
to
say
whether
or
not
they
think
it
would
be
a
good
use
of
of
our
time
so
thoughts.
C
H
I
I,
don't
know
that
we
actually
have
major
content
revisions
here.
So
I
think
we
might
be
okay
with
just
revving
the
documents
and
meeting
in
on
July
so
long
as
there's
some
some
general
progress
right
right.
So
if
we
meet
in
June
what
specific
problems
would
we
be?
Solving
I
mean
we
can
talk
about
other
documents,
or
maybe
the
only
one
that
really
comes
to
mind
is
is
going
over
details
of
the
the
TLs
Biz
document
and
how
that
should
be
organized
that.
C
I
think
there
are
a
couple
things.
One
is
that
we
could
do
if
I
mean
we
need
to
see
and
probably
not
put
them
on
the
spot.
But
I
think
this
is
the
only
real
point
to
meeting
would
be
if,
if
Jan
Fred
will
have
any
of
those
documents
merged
in
by
then-
and
we
can
start
talking
about
the
details
of
whether
you
know
we
thought
they
were
merged
correctly
and
and
so
forth.
C
But
we
also
have
a
couple
of
documents
we
didn't
discuss
on
this
call
that
are
being
proposed
for
the
working
group,
the
COA
document
and
the
status
realm
and
and
loop
detection
document.
And
so
we
could
also,
you
know,
push
on
those
authors
to
rev
those
and
discuss
them
on
the
on
the
same
call.
I
don't
know
if
that
would
be
worthwhile
or
if
we
should
just
do
it
in
July.
So.
A
C
A
C
I
I
I
won't
be
in
person
in
San
Francisco,
that's
for
sure,
and
since
I
have
another
engagement
in
that
time,
I'm
not
exactly
sure
if
I
can
join
remotely,
especially
given
that
the
time
difference.
So
there
is
a
possibility
that
I
won't
be
there
in
San
Francisco
for
the
for
the
Radix
meeting.
So
if
we
want
to
discuss
the
my
document,
then
we
would
either
have
to
do
it
before
or
after
the
ITF
or
someone
else
at
the
ITF
should
have
to
take
over.
C
Yeah
well
we'll
we'll
definitely
talk
about
the
document
of
the
at
the
ietf
weather
I
mean
at
least
its
existence
and
so
forth,
whether
whether
you
can
be
there
or
not,
but
it
would
be
good
to
have
you
for
an
in-depth
discussion
when,
when
the
merging
has
occurred,
or
even
if
it's
you
know,
a
couple
of
the
things
have
been
merged
in,
but
not
all
of
them.
So
that
may
speak
to
it
being
good
to
try
to
have
a
meeting.
C
You
know
in
late,
June
or
or
so
first
week
of
July
is
problematic
because
of
U.S
holidays
and
the
and
I'm
on
vacation
for
most
of
the
first
bit
of
July.
So
it
would
have
to
probably
be
late
late
June
unless
we
can
take
it
offline
and
talk
about
when
what
your
sort
of
timeline
is
for
that.
But
anybody
else
have
a
strong
opinion.
One
way
or
the
other
yeah
Fred
go
ahead.
C
I
I
C
I
I
C
Well,
I
I
was
mostly
going
off
of
I've,
never
been
a
big
interim
person,
but
the
during
the
buff.
For
this
it
was
presented
that
how
the
working
group
would
work
it
would
have
regular
intro
meetings,
which
was
kind
of
a
surprise
to
me,
but
but
I,
don't
I've
just
sort
of
been
going
on
that.
If
people
don't
feel
it's
useful
to
have
regular
interim
meetings,
we
don't
have
to
have
them
I,
I'm
good
with
that.
So
why
I
mean?