►
From YouTube: IETF92-HTTPAUTH-20150326-1740
Description
HTTPAUTH meeting session at IETF92
2015/03/26 1740
A
A
B
B
B
I'm
going
to
this
blue
sheets
are
circulating.
We
have
a
note
taker.
We
have
a
jabber
scribe,
will
do
the
agenda
bashing
in
a
second
and
document
status.
Now
this
meeting
is
going
to
be
dedicated
mostly
to
mutual
off.
So
let's
begin
with
document
status,
anything
else
we
want
to
do
anything
else
on
the
agenda
other
than
we
fat.
Okay.
So,
let's
start
with
document
status,
some
of
our
documents
have
progressed
so
hoba
was
still
a
working
group
document
at
Honolulu.
B
We
have
just
finished
a
working
group
last
call
now
it's
RFC
74
86,
this
group's
first
RFC
basic
authentication,
I
just
started
working
group
last
call
at
Honolulu.
It's
now
past
is
g
review
and
is
in
the
RFC,
a
t-test
q
and
digest
digest
was
just
a
working
group
document.
Since
then,
we've
gone
through
working
group
last
call
and
have
sent
it
to
kathleen.
C
Thanks
so
where
we've
been
discussing
am,
is
that
the
stun
him
order,
the
tram
work
group
is
working
on
a
stun.
A
base
top
did
the
stump
protocol
and
they
would
like
us
to
or
they
would
like
to
use
the
same
mechanism
that
digest
mechanism
on
line
with
what
we
are
proposing
here,
but
they
have
the
quest
to
update
their
the
way
we
calculate
a
one
which
is
a
that
digests
for
username
and
password,
and
they
would
like
to
add
a
assault
to
that
take
calculation.
C
C
But
the
question
is:
is
this
covered
by
the
Charter
first
and
I
think
we
did
add
few
capabilities,
new
capabilities
to
that
digester
I'm
assuming
that's,
may
be
covered
by
the
Charter,
and
it's
all
should
we
try
to
use
that
capability
into
that.
The
current
draft
just
delay
it
and
add
this
capability
and
and
there
and
introduced
in
the
current
draft
or
maybe
introduce
a
create,
a
completely
new
draft
just
to
address
that
aspect
of
a
obvious,
a
request
so
k.
B
C
B
B
Kind
of
sounds
to
me
like
chap
or
md5
challenge,
and
none
of
these
is
a
really
good
authentication
mechanism
and
then
personally,
I,
don't
see
why
we
would
want
to
standardize
at
this
point
in
time
a
kind
of
inferior
mechanism
like
that
I
mean
we're
going
with
basic
and
digest
because
their
historical
and
legacy
and
stuff,
but
right
now,
standardizing
chap,
sounds
to
me
like
not
such
a
good
idea.
But
but
floor
is
open.
Bye.
C
C
D
Be
using
in
that
case,
in
current
latest
scheme
you
first
cherry
request,
visit
any
of
syndication
information
and
returns.
Sabha
the
authentication
server
fastened
edges,
so
service
returns,
the
salt
servers
nones
with
that
in
it
without
any
information
about
the
user
name.
So
in
e,
in
this
sorted
case,
you
must
have
passed
sent
as
user
name
of
us
to
let
server
returns
the
correct
salts
to
eat
for
each
user's.
How
is
it
done
so?
D
D
A
E
This
is
matt
Lipinski,
so
I
just
to
rephrase
the
question
from
the
microphone.
If
a
server
has
a
different
salt
for
every
user,
then
the
server
needs
to
provide
that
salt
to
the
user
right.
So
the
after
the
server
gets
the
username.
The
server
would
then
need
to
send
the
salt
to
the
user
right
and
so
I
believe.
The
question
is:
how
does
this
exchange
map
to
the
existing
messages
for
digest,
authentication.
A
D
A
C
B
B
C
B
F
B
F
So
I
guess-
and
I
haven't
been
in
the
working
group-
so
take
this
with
whatever
grain
of
salt.
You
want
unintended
I
as
long
as
you
can
do
the
addition,
without
breaking
backwards.
Compatibility
for
existing
uses,
I'm,
okay
with
it.
If
it's
going
to
be
a
breaking
change,
that's
a
bigger
deal
and
you
need
to
make
a
working
group
decision
to
do
that.
I
would
think.
Okay.
D
So
I
think
we
need
to
care
whole
discussion
about
the
compatibility
and
acidity,
and
something
like
that
so
I
agree
is
make
up
to
date.
Draft
for
something
like
that
as
a
new
algorithm
to
the
different
from
current
sha-256
but
256
solved.
It
was
something
like
that
to
define
a
new
document
is
a
is
acceptable
if
people
agrees
with
it,
what
update
doing
it
as
a
modification
in
the
short
notice
is
not
a
good
idea
so.
E
Ok,
so
one
more
question
for
the
room
of
this
matt
lapinskas
chair
so
is:
if
this
could
be
done
in
a
backwards
compatible
fashion,
which
is
something
we
still
would
need
to
work
out
on
the
list.
But
if
this
could
be
done
in
a
backwards
compatible
fashion,
are
there
people
in
the
room
who
think
that
this
is
a
a
bad
idea
who
have
serious?
So
there
we
heard
the
backward
compatibility
concern.
Are
there
other
separate
concerns
that
people
have
about
making
this
type
of
change?
G
D
A
C
D
This
is
Utica
was
speaking
in
next,
please
so
I
remember,
I,
have
some
status
update
in
the
the
meeting
before
the
previous
meeting
in
90.
So
after
that,
I
adopted
the
to
accept
several
comments
in
the
discussion
and
added
several
things:
new
things
to
draft
fastest,
as
as
the
same
way
as
a
digesters,
I
incorporate,
RSC,
598,
94
international
swings
and
also
also
implication
in
free
header,
is
now
stuck
under
standardizing.
So
I
also
incorporated
it
in
Prezi.
D
Username
profile
for
normalization
is
fine
except
incorporated
indeed,
and
the
second
change
is
internal
thing,
but
several
people
asked
some
string
format.
Concern
is
the
web
origins
concept,
so
I
changed
to
remove
this
80,
the
string
so
that
it
is,
as
you
can
say,
use
the
same
function
with
the
wave
ologies
during
combustion.
D
Next,
please,
and
for
also
educational
extensions,
I
added
an
explicit
adatom
parameter
for
it.
It
is
because
it
was
not
clear
how
it
with
the
properties
will
be
applied:
pen,
Saba,
centra
user,
multiple
challenges
with
same
authentication
scheme,
but
with
different
levels.
So
now
it's
very
clear
about
that
and
also
I
borrowed
or
stilled
the
mission
proposal
to
other
user
name
parameters
to
the
basic.
So
because
this
my
draft
is
experimental,
and
so
it
may
be
a
good
way
to
test
it,
so
I,
just
quality
and
added
it
next
place
and
for
mr.
D
algorithm
we
just
fix
small
bug
with
a
possible
deniable
service
attacks
related
to
the
mathematica
handling
of
mathematically
invalid
values.
It's
a
technical
issue
and
in
that
I
t90
there
has
been
a
discussion,
was
a
if
we
have
choice
issues
but
finally,
I
have
not
changed
anything
from
the
pre
Toronto
bottom
of
my
draft.
D
So
it
means
that
we
will
still
use
NIST
Cubs
for
this
moment
and
if
we
need
to
change
clubs,
it
will
be
done
in
the
next
ball
division
of
these
algorithms
next
place
and
currently
so
we
have
a
issue
tracker
in
the
working
group
agent.
I.
Think
all
issues
in
the
picked
up
to
the
tracker
is
closed
now
closed.
Next,
please,
and
in
the
sixteenth
of
this
month
I
sent
18
questions
to
the
list
with
all
over,
for
all
of
which
we
we
think
it's
okay,
but
at
the
same
time
we
want.
D
We
want
to
ask
something:
is
it
okay
for
people,
so
I
say,
18
questions
listing
similar
comments
has
been
only
deceived.
So
thank
you
very
much
for
these
comments
and
in
this
presentation,
I
will
repeat
some
of
these
questions
in
the
next
few
slides.
Next,
please
so.
First,
this
is
a
confirmation
question
so
to
send
the
utf-8
strings
in
the
headers
I
introduce
our
HC
five-nine
887
stirring
home
construction.
So
if
user
name
is
like
this
Danny
of
France
as
this,
it
is
encoded
as
a
usual
header
with
quote
to
incorporate
the
space.
D
G
D
Lsd
in
the
age
of
five
thousand,
so
there
has
me
explicit
character,
set
parameter
and
they
are
also
being
a
language
parameter,
but
in
this
draft,
I
want
to
fix
these
parameters
to
the
utf-8
and
with
no
language
parameters,
because
the
rationale
for
that
is.
This
is
not
a
negotiated
parameter
in
this
protocol.
So
if
the
this
string
is
used
as
a
binary
data
in
many
places,
including
input
to
hush.
So
if
a
client,
for
example,
st.
D
simple
one,
it's
okay,
but
for
example,
if
clients
in
the
fifties
or
something
like
some
data,
such
as
a
conversion
of
always
Korea,
so
Sabah
cannot
do
a
reliable
conversion,
and
so
also
in
this
case
there
is
no
me
no
make
no
sense
for
multiple
valid
provision
like
this.
So
I
think
this
can
be
fixed
in
this
should
be
fixed.
Please,
yes,.
D
D
D
With
es
es
s,
password
is
prepared
in
the
press
if
a
show
and
then
incorporated
into
the
hash
functions
and
others.
But
yes
thank
you,
and
so
there
has
been
some
interesting
discussion
of
the
meeting
is
about
thousand
how
it
can
be
handled
if
the
authentication
has
been
succeeded
about
Sabah.
Do
not
accept
that
the
user,
forza
so
authorization
has
been
failed
after
the
successful
authentication.
So
it
has
been
interesting
decision.
So
please
check
it
on
the
mailing
list.
D
Admit
of
us
a
size
or
more
and
not
at
least
attitude.
Gnosis
must
be
active
in
any
time
to
reach
four
seats.
Eyeballs
will
accept
because
it
is
because,
if
Sabah
only
accept
one
not
gladness
at
the
time,
it
will
not
work
well,
even
with
HTTP
1.1,
and
if
we
have
multiple
streams
in
HTTP
to
it
will
be
comfortable.
So
we
have
me
Salamis,
except
several
requests
at
the
same
time,
but
also
if
infinite
number
of
gnosis
can
be
accepted
in
the
from
the
client
server
cannot
perform
the
duplicated
Gnostic
in
the
constant
memory.
D
So
there
is
a
some
kind
of
window
mechanism
into
it.
So
this
is
a
minimum
size
of
the
window.
I
think
SATA
2
is
a
good
value
for
that,
and
also
sister
crediting,
so
is
defined
to
be
60
second
for
the
minimum
so
grant
can
expect.
If
first
we
exchanged
some
session
key,
it
can
be
used
for
the
next
16
seconds.
D
B
A
D
D
B
D
D
Any
other
comments
about
that.
Thank
you
next
please,
and
we
have.
We
always
have
an
eye
on
a
consideration
section
and
there
might
be
yes,
we
have
to
define
some
requirements
day
before
adding
new
algorithms
like
it.
Algorithms
here
means
choice
of
cryptography
and
kilometers,
so
we
should
find
some
labels
for
requirement,
so
I
think
Alex
required
level
is
proper.
But
how
do
you
think
about
that
and
well
sink
things
to
consider
it?
We
have
like
a
secure
shell
protocol.
D
C
A
B
A
A
H
Much
better
we're
talking
about
an
experimental
draft
here
and,
let's
see
morning
range
of
user
IDs,
so
I
think
specification
required
should
be
more
than
enough
right,
so
you
could
use
an
RFC
or
it
could
be
just
a
stable
reference.
Do
you
have
some
reason
why
you
want
RFC
required.
D
H
A
H
Think
it's
going
through
new
another
Rev
soon.
Is
this
something
here?
No
I,
don't
know
why
I
was
thinking
that
might
be
part
of
this
I
think
Marie
might
be,
but
anyway,
one
of
the
comments
I
asked
is
if
a
specification
required
could
be
an
email
to
an
ietf
list,
because
we
know
you
can
reference
those
links
to
that
ietf
email
in
the
archive
and
it's
stable-
that's
not
changing.
So
that's
something
folks
were
kind
of
considering
it.
H
F
H
So
I
believe
that
was
the
plan,
because
I
think
the
Rev
that
just
happened.
We
were
limiting
what
was
actually
revved
in
it
and
when
several
of
us
in
the
iesg
gave
comments,
I
believe
I,
don't
think
I'm
confusing
drafts.
But
I
believe
they
said.
We'd
have
the
opportunity
to
add
these
in
the
next
revision
and
it
didn't
sound
like
it
would
be
far
off
I,
don't
know
how
long
it'll
take
the
publish,
but.
D
Thank
you.
I
will
check
again
for
the
definitions
of
expected
every
rivet
expert
review
and
I
will
put
something
different
from
now
on.
Thank
you
very
much
next
please-
and
this
is
a
actually
difficult
for
special
about
decision
fast,
how
optional
identification
will
be
handled
in
this
experimental
thing,
so
my
proposal
is
actually
this
was
compiled
before
the
discussion
of
HTTP
piece
1.1.
So
my
proposal
is
to
other
new
head
explicitly
specifying
optional
opportunity
for
authentication.
D
So
the
good
point
for
this
is
it
is
guaranteed
by
to
be
ignored
by
all
the
clients,
because
world
grant
the
header
just
sings
as
a
some
unknown
attribute
the
content,
so
it
will
be
completely
ignored
so,
but
in
this
number
is
a
HTTP
piece
version
of
the
HTTP
authentication
header,
so
this
RFC
explicity
says
saba
may
generate
a
Tubba
Tubba,
Tubba
authentication
header
within
other
response
messages,
as
a
means,
others
from
2401
header
to
indicate
the
spring
might
affect
the
response.
So
in
the
text
this
means
it
can
be
used
for
optional
authentication.
B
A
D
D
Thanks
next,
please
so,
and
one
criticism
to
our
draft
is
simply
the
string
is
too
long.
Do
you
think
this
is
too
long
for
the
HD
favor,
because
it
is
not
only
made
a
pass,
a
feeling
question,
but
people
complaining
why
you
do
this
kind
of
long
headers,
but
in
their
case
hdtvs
people
trying
to
compact
the
headers
at
math
most
as
possible,
so
I
would
like
to
change
it
little
bit
like
this.
Is
it
okay
for
me
to
change
this?
D
B
D
Thank
you,
okay,
next
piece
and
I
know
consideration
again.
This
is
the
final
question
so
intention
what
is
is
this
hey?
Does,
for
example,
just
as
my
head
Mkhize
proposal
to
the
basic
several
people
proposing
some
a
small
extension
to
the
HTTP
authentication,
but
because
it
the
header
field,
is
defined
for
each
authentication
schemes.
D
You
cannot
do
it
in
the
share
the
fashion,
so
you
can
propose
small
extension
to
basic,
but
it
cannot
be
used
by
digest
so
this
headlight,
this
experiment
that
authentication
extension
header
is
a
some
client
can
be
used
as
a
catcher
extension
point
for
trivial
authentication.
Extensions
like
you
can
use
it
for
only
for
one
day
or
something
like
that
or
you
should.
You
can
use
this
username
for
syndication
tires
or
something
like
that.
So
it's
very
yeah
katal
thing,
so
we
should
be
good.
There
should
be
a
ruse
requirements
as
authentication
cryptographic
algorithm.
D
A
E
A
D
D
Current
hint
means,
like
sorry,
client
hint
means
a
cramp
in
this
extension.
Grant
can
ignore
any
directly
with
each
grant
does
not
understand,
are
not
willing
to
follow
us
all
but,
for
example,
sub
in
HTTP
authentication
server.
May
we
have
explicit
robot
header
from
service
to
client
but
client,
because
current
always
has
a
credential.
D
Saba
cannot
force
screens
to
about
forget
about
username
in
Posada
credential,
but
summer
camp
in
this
extension,
sub
I
can
tell
clients
that
okay
performing
robot
this
moment
is
good
for
users
about
the
user
interface
designer.
Something
like
that.
So
I
called
that's.
Why
I
call
it
a
crayon
teens.
Other
things
is
the
username
extension
like
II,
so
if,
for
example,
for
Reuters
or
some
appliances,
there
is
only
one
user,
but
it
in
that
case,
without
syndication
requests,
you
may
maybe
you,
the
user
name.
You
want
to
use
it
this
one.
D
B
D
G
B
D
G
G
D
G
D
D
G
B
D
Reason
for
seeking
use
of
sequence
number
against
the
Nazis,
if
crying
since
thousands
of
London
ounces
before
and
in
this
in
the
1000
in
fast
request,
tsubame
strictly
the
nose
like
value
against
1,000
various
numbers,
so
in
current
edges,
I
guess
notification
check
is
not
done
because
of
that,
so
that
we,
for
this
repeat
repeat,
attack
is
critical,
so
we
should
use
bar
which
can
be
checked
reliably
that
the
intention
for
using
is
a
countess.
Thank
you.
Thank
you
very
much.
B
D
B
D
D
B
B
G
A
B
G
I
guess
I
do
have
one
sort
of
larger
issue
that
we
could
perhaps
talk
about
as
the
group.
So
in
terms
of
what
the
client
and
the
server
need
to
do
for
their
messages,
they
send
their
verification,
behavior.
There's
currently,
I
think
in
section
10
of
the
main
document,
there's
both
a
list
of
a
sort
of
general
rules
and
then
there's
also
a
flow
chart.
Diagram
with
steps
for
the
flow
chart
in
prose
text
is.
D
G
D
Bad
yeah,
that's
a
question
because
first
I
will
explain
my
intention
because
it
says
copy
other
state
machines.
State
hunting
is
very
important
for
client-side
for
security,
so
I
intentionally
not
specific
state
machine
to
the
main
draft
so
that
even
implemented
without
a
deep
security
knowledge.
We
are
not
confused
about
that,
but
request
comments
from
the
meeting
Renee.
This
is
that
you,
it
should
be
more
of
a
specification
requirement
based
so
I
added
the
Swiss
kid
get
some
pot
fast.
So
this
is
this
kind
of
steps.
D
B
D
B
D
D
G
D
D
B
A
G
Yeah,
it's
oh.