►
From YouTube: IETF95-HTTPAUTH-20160406-1620
Description
HTTPAUTH meeting session at IETF95
2016/04/06 1620
A
B
So
welcome
to
the
HTTP
authentication
working
obsession.
New
sheets
are
I'm
going
to
run
blue.
Please
write
your
name
in
wonderful
and
besides,
you
also
have
to
read
and
accept
the
contents
of
the
next
slide,
which
is,
thankfully
not
in
Spanish.
B
Okay,
sure
you've
seen
this
not
once
but
several
times.
So,
let's
start
with
the
agenda.
I've
got
the
note
world
which
we've
already
seen
agenda
bashing,
which
we'll
get
to
right
away
and
the
blue
sheets
are
going
around.
Then
we're
going
to
talk
about
document
status
and
mutual
off,
because
the
mutual
of
set
of
documents
is
the
last
thing
that
we
have
in
our
charter
and
then
we'll
see
a
presentation
by
Iran
for
rough
draft
use
of
srp
method
and
if
we
have
time
open
mic
anything
missing
there
or
anything.
B
Ok,
so
the
bait,
sick
and
digest
authentication
grafts
were
published
on
September
30th.
Now
that's
before
Yokohama,
but
since
we
didn't
meet
in
Yokohama
covering
that
as
well,
they're
RFC,
76,
17
and
76
16,
respectively.
There's
also
an
HD
bist
document
for
operating
authentication
method
that
76
15.
That
was
three
document
set
scram
published
just
under
a
month
ago,
thanks
Alexei,
and
we
got
revised
versions
of
future
of
every
document.
In
the
mutual
off
set
of
documents.
We've
had
language
review,
which
say
in
reality.
That's
everything
we
would
get.
B
We
might
get
in
a
general
review,
so
that's
completely
at
early
for
the
mutual
of
documents.
So
first
thing
a
big
thank
you
to
Cory
Banfield,
Melinda
shore
and
Peter
ye
for
reviewing
these
documents,
and
they
can
get
as
many
stars
as
they'd,
like
all
the
stuff
that
we
have
to
give
and
next
about
mutual
off.
So
the
plan
going
forward
is
to
discuss
it
here.
B
There's
about
four
open
issues:
I
have
new
versions,
incorporating
both
the
language
reviews
and
whatever
we
decide
here
by
the
end
of
april,
then
go
to
working
group
last
column,
since
this
is
a
set
of
three
documents
and
they're
interdependent
and
altogether
pretty
large
we're
going
to
let
it
go
through
most
of
May
and
then
assuming
everything's.
Okay,
we
request
publication
early
June
and
then
we
might
have
rfcs
by
the
time.
B
B
B
A
B
C
Ok,
so
yeah
just
a
we're
trying
to
wrap
up
late
in
this
say
this
work.
So
a
yutaka
has
a
few
issues
that
we
would
like
that
work
group
to
help
us
a
and
maybe
help
I'm
a
close
those
am
and
let's,
let's
keep
going
to
next
one.
It's
not
ok
first
day,
but
thank
you
for
that,
reviewers
him
and
three
of
them
and
each
one
may
reviewed
a
different
document.
That
was
very
helpful.
C
C
So
the
first
one
is
talking
about
an
optional,
a
authentication,
a
applicability
him
talking
about
a
Alto
in
a
to
like
he
has
a
specific
text
talking
about
successful
HTTP
responses
and
current
ex
talking
about
200
and
200,
a
206
and
others,
and
he's
suggesting
that
talk
about
200
or
2x
X.
Instead,
the
more
specific
about
those
responses,
say,
m
and-
and
he
has
few
comments
there-
about
the
requirements
and
and
different
responses
that
applicable
not
applicable.
So
any
anybody
has
any
comments
on
this
one.
B
So,
if
Andersen
quickly,
the
current
text
says
the
good
responses
are
200
206
and
the
suggestion
is
a
0
NE,
200
and
anything
could
be
okay
and,
in
fact
only
401
is
really
bad
thing.
Well,
the
bad
view
that
we
expect
that
a
good
reflection
of
their
concern
I
think
that
that's
consent,
yeah
aleksei
aleksandrovitch.
D
E
B
D
B
C
D
B
B
F
My
lady
optional
feature,
so
the
main
purposes
is
in
some
life
existing
password
databases
already
have
some
kind
of
md5
sha-1
hash
and
if
we
add
this
feature,
users
can
combat
existing
databases
to
the
nuba
literacy,
education,
possible
databases.
But
of
course
it's
not
needed
for
any
new
databases,
so
I
intentionally
dropped
a
new
hashtag
Elizabeth
like
shuttle,
or
something
like
that.
But
maybe
it's
really
weird
why
many
people
asks
us
that
why
you
only
include
very
older
organisms,
so
it's
intentional,
but
not
really
understandable
for
many
readers.
F
B
H
B
H
Those
ones
won't
have
the
additional
ash,
probably
and
adding
a
hash
would
allow
to
allow
someone
to
migrate.
The
password
database
is
basically
saying
that
you
I
know
the
fine
text
to
the
passwords
we're
going
to
go
one
layer
of
hashing
here,
it's
not
like
we've
got
a
big
dictionary
to
search
or
anything.
It's
a
low
entropy
secrets
that
we're
going
here,
I.
H
H
C
D
B
A
E
The
last
idea
for
the
last
version,
and
but
of
course,
we've
added
the
latest
stuff
as
well,
so
as
a
peer
for
those
who
don't
know
is
a
password
authenticated
key
exchange.
So
the
two
sides
authenticate
wear
the
shirt
secret
secret,
which
is
a
password
so
short,
human,
memorable
shirt
secret,
and
this
is
an
augment,
augmented,
password
authenticated
key
exchange,
which
basically
means
that
the
server
side
doesn't
need
to
hold
the
actual
password.
E
B
E
So
now,
I
and
Justin
the
username,
the
server
a
authenticates
with
a
challenge
that
contains
all
this
stuff,
the
large
prime
itself,
the
generator.
So
the
literal
values
of
the
diffie-hellman
group,
a
algorithm
salt
and
the
server
public
key
and
those
values
are
computed
and
go
back
and
forth.
Two
rounds
for
the
whole
thing,
with
the
proof
of
possession
on
both
sides.
E
D
Alexa
can
I
ask
clarifying
question
on
previous
slide.
Yes,
you
don't
seem
to
have
any
way
to
correlate
requests
and
responses
between
different
round
trips
to
have
a
session
ID.
I
E
C
E
D
C
D
Ok,
if
it's
not
well
go
ahead,
hi
and
you
think
about
that,
my.
H
E
E
E
I
E
C
C
I
B
B
So
I'd
like
like
to
remind
the
group
that
our
Charter
is
about
creating
small
experimental
documents
and
our
level
of
review
is
not
the
same
as
for
a
standards
track
documented,
but
I
was
pretty
obvious
in
the
previous
documents
that
would
make
basic
and
digest
notwithstanding
so
like
to
know
if
the
people
in
this
room
well,
of
course,
we'll
take
it
to
the
list
like
everything
else,
but
they
lack
half
the
people
in
this
room.
Think
this
idea
is
worth
pursuing.
Unless
steven
has
something
to
channel
first
I.
K
C
B
So
when
this
working
group
was
formed
by
in
was
I
when
we're
doing
the
buff
that
in
the
doctrine
creating
this
working
group,
I
thought
that
we
were
going
to
get
like
four
or
five
different
cakes.
I
was
half
expecting
to
get
a
dragonfly
one
that
didn't
happen,
and
so
we
ended
up
just
with
mutual.
So
it's
not
really
surprising
that
we
have
another
one,
but
no
as
far
as
I
know,
there's
no
other
people,
Cuba
kids,
ooh,
and
waiting
to
submit
more
drafts
with
more
pigs
in
the
space.
I
Then
that
was
not
a
challenge.
No
I'm
just
saying
I'd
be
happy
to
write
a
draft,
but
it
doesn't
make
sense
to
do
a
pink
at
this
at
this
level,
so
I
mean
I,
guess.
The
reason
you
don't
have
more
is
because
I
guess
other
people
are
by
looking.
What's
the
point
of
doing
a
peg,
it's
gonna
throw
away
the
result.
You
know
if
the
benefit
is
opaque,
you
know
is
authentication
loses
a
dictionary.
Tagging
you've
got
this.
You
know
special
key,
it
has
perfect
secrecy
and
they
throw
it
away.
I
C
B
K
H
D
K
B
B
F
K
E
We
know
what
we
get,
we
don't.
We
know
that
we
don't
get
any
binding
written
between
the
first
authentication
session
and
subsequent
as
such
as
well.
That's
clear,
however,
I
think
that
mutual
authentic
immutable
take
based
authentication
such
as
this
one
in
the
present
in
the
presence
of
normal
fearless
server
authenticated
with
you
know,
a
very
sign
issues
that
I
think
that
actually
adds
a
lot
to
the
security
of
the
connection.
B
Okay,
so
does
this
change
anybody's
mind
so
that
now
they
think
that
it
is
worth
pursuing
not
much
well,
assuming
that
we
decided
that
it
was
worth
pursuing.
Do
you
think
it's
appropriate
for
this
group,
yeah,
probably
yeah?
No
other
group
would
take
this.
G
B
So,
and
would
anybody
be
interested
in
reviewing
offering
text
yeah,
maybe
Alexei
and
and
then
assuming
that
we
owe
doing
count
on
area
director
for
having
the
time
to
review
and
offer
text?
Okay
and
well
I
think
we
can
skip
the
last
question.
So
my
view
of
the
few
of
the
room
is
that
there's
really
not
much
interested
in
accepting
this?
We
will
take
it
to
the
list.