►
From YouTube: IETF94-TOKBIND-20151102-1710.webm
Description
TOKBIND meeting session at IETF94
2015/11/02 1710
C
A
B
B
A
C
All
right,
good
evening,
everybody
konichiwa
for
the
next
for
the
session.
We're
gonna
be
talking
about
token
binding
next
slide,
please
just
to
give
you
a
quick
overview,
I'm
going
to
recap
token
binding
for
people
who
haven't
encountered
this
before.
We
talked
a
little
bit
about
the
changes
that
happen
since
the
last
meeting,
and
we
get
into
a
little
bit
of
detail
about
the
threat
model
that
we're
trying
to
address
next
slide.
Please.
C
The
problem
is
that
if
this
cookie
is
actually
stolen
by
some
actor
in
the
network,
no
one
of
a
variety
of
mechanisms,
a
cross-site
scripting
attack,
a
network
man,
the
middle
malware,
milling
machine,
though
this
actor
can
now
use,
can
wield.
The
cookie
can
present
this
cookie
and,
as
I
see,
steal
the
section
and
what
we're
trying
to
do
is
throw
cryptography
at
this
problem
and
make
it
possible
for
the
server
to
detect
when
this
is
happening
so
that
we
can
deny
the
attacker
of
that
session
next
tightly.
D
B
C
Right,
so
the
key
idea
is
that
the
client
essentially
built
it
could
be
a
infrastructure
for
a
second
factor.
So,
in
addition
to
the
cookie
that
the
browser
presents
to
the
server,
it
presents
proof
that
it
has
the
right
to
wheel
the
cookie,
and
it
does
that
by
basically
creating
a
key
pair
for
use
with
that
server
it
I'm
to
protect
privacy.
We
use
our
different
keys
for
different
servers.
C
Obviously
we
want
to
keep
our
private
key
safe
so
that
new
ears
can
use
them.
The
client
discloses
the
public
key
to
a
server,
and
then
it
proves
to
the
server
by
signing
a
secret.
In
this
case,
it's
the
ekm,
the
ported
King
material
in
the
TLS
handshake.
It
proves
to
the
server
that
it
owns
the
private
key
and
the
result
is
that
the
server
can
say.
C
If
we
don't
have
support
explicit
support
for
Federation
in
the
token
binding
protocol,
the
ID
token
that
is
issued
by
the
entity
provider
will
be
bound
to
the
identity
provider
and
next
and
so
hen.
It
is
presented
by
the
client
to
the
relying
party
there's
no
way
for
the
relying
party
to
actually
verify
that.
This
token
should
be
acceptable.
C
You
need
is,
for
the
ID
token,
to
actually
bound
to
the
relying
party
so
that
the
ID,
the
line
party,
can
actually
verify
that
the
is
supposed
to
be
used
by
the
track,
and
in
order
to
do
that,
when
the
identity
provider
issues
the
token,
it
should
actually
bind
it
to
the
relying
parties.
Token
binding
key,
not
the
identity
providers,
took
many
nights
like
these,
and
we
do
this
by
allowing
the
relying
party
to
signal
the
client
to
disclose
its
token
binding
ID
to
dilatory
provider
when
it
goes
through
this
redirect.
C
So
the
presence
of
this
new
header,
the
include
referred
protein
binding
header,
tells
the
client
that
it's
okay
for
it
to
disclose
its
token
binding
ID
to
the
editing
provider,
so
that
the
next
stage
were
called
the
ID
provider
can
a
key
issue
a
token
that
is
bound
to
the
rank
pari,
and
so
the
flow
basically
takes
the
form
where
the
redirect
happens.
The
relying
party
sends
a
message
to
the
client
saying,
add
your
token
binding
ID.
C
Add
the
token
binding
idea
that
you
use
for
me
to
the
request
that
you
send
to
the
IV
provider,
and
this
token
binding
header
now
contains
two
pieces
of
information.
It
contains
the
token
binding
ID
that
the
client
would
normally
use
for
the
auditory
provider,
which
is
how
the
identity
provider
can
verify
that
its
interaction
with
the
client
and
legit
thanks
lightly,
and
it
also
contains
a
second
token
binding
ID
called
the
referred
protein
binding
ID,
which
is
the
token
binding
ID
that
the
client
could
use
with
the
relying
party.
C
So
now,
when
the
irony
provider
issues
the
token
it
actually
binds
it
to
the
referred
for
combining
ID,
which
is
the
token
by
any
idea
that
the
client
would
use
with
the
relying
party
and
when
it
presents
a
token,
it
had
the
correct
information
in
there.
So
now
the
client
presents
the
IDP
issued
ID
token
to
the
relying
party
and
it
has
the
correct
information
in
there.
C
So
what
changed?
From
the
previous
meeting
to
this
meeting
the
busy
at
the
end
of
the
last
meeting
of
basement
discussion,
we
change
the
name
of
the
header
from
secto
combining
hell
to
token
binding.
The
motivation
still
remains
the
same.
We
want
that
header
to
be
protected
and
not
be
able
to
be
manipulated
by
script
and
other,
especially
by
Scripps.
C
Basically,
the
fear,
lest
we
didn't,
have
enough
randomness
in
it,
and
it
was
a
little
unsafe
or
against
some
attacks,
and
then
we
updated
the
security
considerations
section
of
the
spec
arm,
basically
discussing
two
key
items:
why
do
we
want
to
distill
of
scripts
from
setting
the
token
binding
header,
and
why
do
we
need
to
actually
prove
possession
of
two
keys
for
our
Federation
next
like
these?
So
let's
look
quickly
at
the
track
model
that
we're
trying
to
solve
here.
C
If
the
the
presenter
of
the
cookie
or
the
token
is
unable
to
prove
that
it
owns
the
private
key,
something
is
wrong
and
it
is
able
to
deny
the
completion
of
that
session
exactly
so.
This
basically
two
two
avenues
of
threat:
one
is
an
attacker
uses,
a
victim's
private
key
and
the
other
is
the
attacker
makes
a
victim
use
or
I.
Think
you
present
a
token
binding
header
that
uses
a
curse.
C
Public
key
Larry
essentially,
is
that
if
the
attacker
can
convince
a
client
to
use
a
header
that
it
provides,
the
token
that
is
issued
will
be
bound
to
a
private
key
held
by
the
attacker,
and
the
tactic
will
be
able
to
continue
the
session
based
on
that
next
tightly
to
protect
the
victims.
Private
key
there's,
basically,
two
key
countermeasures:
one
keep
the
privateer
secret
and
I
believe
you
might
want
the
private
key
to
be
back
in
hardware.
So
it's
likely
not!
Oh,
it's
not
possible
to
be
exfiltrate
from
the
device.
C
The
second
is,
we
don't
transmit
it
over
the
network.
So
if
there's
the
man,
the
middle
in
the
network,
it'll
never
see
the
private
key
next
slide.
Please
to
protect
our
to
prevent
the
attacker
from
being
able
to
convince
the
client
to
use
its
token,
my
new
to
users,
private
key
I'm,
sorry,
perfection,
yeah,.
E
C
E
C
So
you
know
to
prevent
the
attacker
from
essentially
creating
a
header
that
the
client
presents
that
and
making
the
client
present
or
head
of
creative
l
a
backer.
The
first
thing
we
need
to
do
is
make
sure
the
EK
m
is
secret,
because
if
they
came
is
in
secret,
then
it
makes
it
possible,
for
someone
well
actually
came
to
use
their
own
keys
to
sign
it
and
present
next
slide.
The
second
is,
we
don't
want
an
attacker
to
be
able
to
set
the
token
by
any
header,
and
the
idea
here
is
if
well,
I,.
F
C
F
C
So
the
key
idea
is
we:
if
it's
so
one
more
layer
of
Defense
right,
just
it
being
public
is
not
it's
not
bad,
but
in
combination,
if
example,
two
or
three
things
pale
at
the
same
time,
then
it
becomes
an
issue
right.
If,
for
example,
you
can't
export
the
if
the
etm
is
kept
secret,
then
nobody
had
access
to
it
and
there's
no
big
no
way
they
can
actually
generate
the
signature
that
is
needed
to
make
the
purple
work.
Break.
Ok,
I.
F
Mean
I
guess:
yeah
I
certainly
agree
it's
good
for
to
be
secret,
but
on
what
I'm
concerned
about
is
that
if
it's
a
logic
of
this
protocol
depends
on
it
being
secret,
then
I'd
like
to
understand
what
the
proof
structure
is
because
I
was
not
actually
like.
That's
not
correspond
to
my
current
model
so
like
I
guess
what
I
be
interested
but
I,
be
der
shouldn't.
F
Seeing
would
be
a
description
of
it
as
you're
gonna
attack
that
rely
to
that
UK
that
that
I
mean,
if
you
imagine
imagine
like
having
a
proof
of
the
protocol
right
and
you
say
like
what,
what
conditions,
what
conditions,
including
the
ekm
being
public,
have
to
obtain
for
the
protocol.
You
broken
I've
been
written.
If
you
think
this
important
security
populates
understand
what
it
was
right.
D
This
this
is
particularly
relevant
I.
Think
in
the
in
the
Federation
case.
I
think,
isn't
it
that's
great
because
you
can
you
can
learn
the
gore
origin
part
the
the
bit
that
was
intended
for
the
IDP
are
typically
just
by
being
the
IDP
and
if
you
were
able
to
learn
the
other
part,
some
fashion
you
can
I.
F
Sit
sit
so
to
be
clear.
This
is
an
artifact
of
not
using
a
sec
pepper
that
I've
correct
that
if
you
use
the
SEC
header
that
so
let
me
see
if
I
can
restate
this
as
I
understand
the
situation
is
that
if
the
e
km
is
leaked,
then
the
attacker
can
the
attacker
can,
depending
on
timing,
potentially
impose
their
own
on
their
own
sec
header
they're
in
their
own,
though,
and
hetero
that
opposes
are
done
in
the
protocol,
so
I
asked,
then
why
are
you
not
using
a
second.
F
F
C
And
finally,
for
the
third
come
to
measure
is
for
the
protocol
to
work.
We
want
to
make
sure
whenever
the
token
binding
header
is
presented
to
a
server,
it
always
verifies
that
the
client
can
prove
possession
of
every
key.
That's
in
that
header
and
the
idea
here
is,
we
do
not
want
a
free
sample,
a
network
man,
the
middle,
to
be
able
to
tack
on
things
into
the
header
that
point
at
keys
that
are
in
control
of
that
attacker.
C
So
the
end
result
of
this
essentially,
is
that
whenever
or
so
were,
seized
a
token
binding
header,
it
can
confirm
that
the
client,
a
key
owns
the
private
keys
of
every
token
binding
ID
that
is
in
that
header.
Next
Eyed
Peas
I'm
try
thing
cleared,
so
this
is
kind
of
pretty
much
where
we
are
at
the
end
of
the
revisions
after
the
last
meeting
and
based
on
discussions
that
we've
had
in
the
world
group.
So.
B
We
know,
and
we
actually
really
went
back
and
reviewed
the
notes
from
both
meeting,
and
there
was
actually
a
discussion
about
the
SEC
header.
The
the
consensus
was
that,
even
though
we
could
work,
you
couldn't
see
a
like
a
huge
use,
for
it
wasn't
seen
as
a
bad
idea
right.
So
why
not
just
add
it
I
think
was
actually
the
contribution
from
last
meeting
and
it
would-
and
the
group
also
called
for
some
sort
of
threat
analysis
to
being
should
be
in
the
document.
B
D
Mountain
Thompson
over
the
past
I
think
couple
months,
we've
seen
a
number
of
interesting
thing.
Come
things
come
up
in
this
sort
of
general
area
that
may
be
of
interest
to
people,
and
it
refers
ear
to
the
duplicate
signature
attack
that
was
found
on
the
acne
protocol.
The
proposal
looks
made
there
and
some
of
the
unknown
key
share
stuff.
D
Think
I,
don't
know
if
it's
unreasonable,
but
having
that
as
a
precondition
for
working
good
last
call
would
make
me
a
whole
lot
more
confident
about
this.
That
said,
I
know
how
much
effort
that
is
and
I'm
not
necessarily
going
to
hold
anyone
to
stand
it
higher
than
I
would
expect
myself.
So
I
completely
understand
if
no
one's
willing
to
put
up
the
resources
for
that,
but
I
think.
D
D
G
Under
a
Popoff,
so
to
answer
the
question
of
the
chairs
asked
about
the
degree
that
you
know
the
authors
believe
this
is
ready.
I
believe
this
is
approaching.
This
is
converging
pretty
well,
and
you
know,
Microsoft
has
an
implementation
of
this.
Google
has
an
implementation
of
this.
We
are
pretty
close
to
actually
at
Microsoft
were
pretty
close
to
enabling
this
by
default
in
in
the
browser.
So
we
believe
it's
pretty
good.
B
G
B
Just
for
the
record
for
the
work
europe,
we
actually,
the
chairs
have
actually
requested
early
allocation
of
some
of
the
code
points
from
my
anna
and
I'm
not
exactly
sure
where
we
are
with
that
process.
But
you
know,
given
that
you're
saying
this,
is
you
you
guys
feel
that
this
should
be
close
to
working
group
class,
wld,
see
and
maybe
we're
going
to
overtake.
B
We
may
not
sort
of
have
another
day
allocation
before
we're
actually
done
right,
but
so
I'm
I'm
just
trying,
because
the
list
has
been
fairly
quiet
right
over
the
last
couple
of
months.
I'm
not
trying
I'm
trying
to
figure
out
whether
that
means
that
everybody's
happy
or
whether
nobody
is
reviewing
this
right.
I
mean
the
fact
that
there
are
implementation,
certainly
a
good
indication
that
people
are
actually
more
or
less
like
what
they
see.
So
one
issue
sort
of
being
resolved.
Today.
A
F
So
so
one
thing
I
think
actually
is
important
on
is
to
be
Minnesota.
First
of
all,
I
think
more
info
later
right,
it'd
be
great
to
have
on
the
oprah
para
for
a
camera
model
on,
though
it
is
hard
to
do,
is
a
lot
of
work
and
getting
the
and
understanding
and
really
mile
in
the
protocol
a
crow
is
you
can
cry
to
be
hard?
F
The
fundamental
assumption
is
that
you're
at
your
authentic
ating,
with
a
bearer
token
I,
you
a
cookie,
and
this
is
about
making
it
not
possible
to
move
the
cookie
around,
and
so,
if
this
Mexican
prevails,
then
you
fall
back
effectively
and
that
we're
assuming
you're
doing
you
know
TLS
anyway,
and
we're
summing
your
fans
tificate.
So
even
total
fireless
mechanism
should
not
need
to
compromise
the
world
on
so
maybe
is
purely
a
matter
of
you
know.
Writing
that
text
the
document,
but
but
that's
certainly
I'd,
be
more
antsy
about
this.
G
F
D
Yeah
yeah
yeah
I,
don't
I,
don't
don't
think
we're
at
all
prepared
to
deal
with
the
possibility
that
something
like
this
might
happen
in
the
clear,
for
instance,
because
then
the
binding
the
binding
between
various
things
is
it.
But
if
but
yeah
a
tunnel
compromise
would
would
would
probably
lots
of
say.
The
private
key
of
a
client
would
probably
not
be
the
endless.
No.
F
I
guess
what
I
mean
is
yeah,
that's
what
I
vice.
Why
me
to
say
is
magic,
I'm
we're
just
getting
on
the
weasel,
but
but
imagine
imagine
how
to
imagine
you
had
a
mechanism.
We,
the
public
key,
was
with
a
puck
with
it
sort
of
binding
the
public
key
to
the
identity
or
where
the
tower
thee
or
worthy.
You
know
the
the
cookies
were
not
inherently
secret.
F
C
Right
so
basically,
if
they
were
a
loner
ability
in
the
protocol
actually
failed,
all
it
does.
Is
it
things
you
back
to
where
we
are
right
now
here
the
cookie
can
actually
move
from
one
sheet
with
the
few
machine
and
wheel
it
and
really
what
this
protocol
is
going.
Is
it's
aimed
at
preventing
preventing
that.
B
G
Ok,
my
name
is
Andrea
pop
off
I'm
with
Microsoft
and
I
will
talk
about
the
changes
that
were
made
in
the
token
binding
negotiation
draft
and,
in
the
token
binding
protocol
draft
since
the
previous
ITF
meeting,
so
we're
starting
with
the
negotiation
draft.
Basically,
you
know
to
give
a
broad
overview.
The
two
main
changes
that
were
made
in
this
time
frame.
One
of
them,
was
based
on
the
feedback
that
we
received
in
Prague,
which
was
that
we
wanted
to
have
an
actual
token
binding
protocol
version
negotiation
rather
than
token
binding
protocol
indication.
G
So
previously
what
we
were
doing
was
you
know
the
client
was
indicating
in
in
a
TLS
extension,
the
the
token
binding
version
to
the
client
supported
and
the
server
either
echoed
that
and
then
then
we
had
token
binding
going
on
or
or
the
server
just
the
connection
continue
without
Oh.
Combining
the
server
would
not
echoed
the
diversion
to
the
client
offered
this.
You
know
we
decided
that
that
was
not
expressive
enough,
that
we
wanted
some
kind
of
negotiation.
G
So
in
this,
in
this
version,
I
am
introducing
a
TLS
style
negotiation,
where
the
client
offers
the
highest
version
of
the
token
binding
protocol
that
the
client
supports.
And
then
the
server
responds
with
the
lower
of
the
client,
supported
and
server
supported
versions
and
we'll
see
that
in
this
draft,
if
we
can
scroll
down
to
to
some
substantive
changes.
G
You
will
see
that
the
text
has
been
changed
to
do
exactly
that,
so
the
client
offers
the
highest
version.
The
client
supports
and
the
server
echoes
that
and
the
server
and
the
server
responds
with
the
lower
of
the
client
supported
version
and
the
service
supported
version.
This
is
this
is
how
TLS
version
ago
she
ation
roars
it's
a
fairly
simple
mechanism.
G
G
G
Yes,
so,
and
if
we
move
further
down
so
this
is
we'll
see
probably
the
next
change
that
was
made,
which
is
we
switched
from
the
use
of
the
HLS
unique
to
the
extracted
key
material
from
the
TLS
session.
There
was
a
discussion
was
a
thread
on
the
mailing
list,
where
we
decided
the
TLS
unique
was
not
secure
enough.
It's
few
bites
that
could,
in
principle
be
replicated
so
men
in
the
middle
could
in
principle,
produce
a
session
with
the
client
and
the
server
that
have
the
same
to
us,
unique
and
that
would
break
token
binding.
G
A
A
G
So,
okay,
so
once
we
made
the
previous
changes,
we
also
looked
at.
We
looked
at
our
here.
Please
stop
here,
so
we
look
at
our
token
binding
key
parameters
IDs
and
we
found
that
we
no
longer
need
the
hash
suffixes
on
them,
because
the
extended
keying
material
is
the
value
that
we
directly
sign.
So
we
don't
need
to
hash
anymore,
so
you
don't
need
to
negotiate
the
hash
function.
F
F
F
G
F
For
that,
ok,
so
I
think
this
may
need
a
little
more
specification.
Yes,
I
see,
I
see
you,
a
question
will
will
clarify
that
yeah
and
in
for
PSS
you
also
need
to
specify
I
think
on
the
I
didn't
see
the
the
name
of
the
algorithms
used
for
the
salt
generally
good
right
sounds
mr.:
hey
I
mean
I.
I
think
I
think
it's
great,
I
think,
is
probably
find
the
tide
John
Williams
on
in
some
fixed
Hawaii
I.
Just
think
you
may
need
to
like
be
a
little
water
right.
F
This
is
sort
of
trivial
point,
but
in
my
merits
and
discussion
on
in
the
in
the
introduction
in
the
client
in
the
client
text
to
subscribe
generating
the
extension,
it
says
that
you're
supposed
to
list
the
parameters
and
descending
order
price
right
and
in
the
server
text
processing
the
extension.
It
says
you're
supposed
to
pick
the
one
you
like
best
as
in
the
client
list
right,
and
so
those
seams
are
not
how
much
do
each
other
and
I
want.
That's
me:
that's
how
the
server
to
ignore
the
clients
order?
G
G
Here
I
recommend
and
saying
should
yeah,
but
in
principle
you
could
imagine
the
server
that
that
honors,
the
clients
preference
sure
as
as
a
non
default
mode.
That's
what
I
was
thinking
about.
So
it's
useful
I
think
it's
more
useful
for
the
client
to
offer
some
kind
of
ordering
than
to
offer
no
ordering
because
it
could
in
principle
be
used.
Although
that
to
me
you
know
to
me,
the
server
should
be
driving
this.
That's
why
I'm
saying
should
I
can.
G
Okay,
so
in
the
in
the
protocol
spec,
we
see
the
same
changes
echoed
so
we're
here
we're
using
exported
keying
material
instead
of
TLS
unique
down,
please
okay,
so
this
is
just
yeah
but
better
references.
Let's
move
on
okay,
so
in
the
actual
message
formats
we
were
able
to
simplify
the
message
formats
now.
So
what
I'm
doing
here
is
in
the
token
binding
message
I
am
using
the
same
token,
binding
key
parameter
ideas
that
we
have
negotiated
in
the
TLS
extension.
G
G
D
A
G
That's
what
we've
got
here
also
we
figured
out
that,
since
the
elliptic
curve
is
already
part
of
the
key
parameters,
we
can
just
use
ec
point
structure
directly.
We
don't
need
to
put
the
same
information
in
two
places
in
the
message,
so
this
was
another
simplification
that
who
made
and
let's
scroll
down
a
little
bit.
G
So
this
section
talks
about
specifically
what
parameters
were
supplying
to
the
key
material
exporters.
So
there
is
a
label
exporter
protein
binding.
It
starts
his
prefix
with
the
string
explorer
to
to
avoid
collisions
the
context
application
context.
Data
is
now
in
our
case,
and
the
length
of
the
key
material
that
were
exporting
is
32
bytes.
E
G
The
you
know
at
the
previous
meeting
we
had
a
comment
asking
asking
us
to
provide
some
explanation
of
why
we
need
extensions
and
I'm,
giving
an
example
use
of
extension
over
an
extension
of
the
token
binding
protocol,
which
is
to
provide
attestation
to
provide
a
way
for
for
the
server
to
confirm
that
the
client
actually
secures
the
key
in
a
hardware
module.
So
for
that
purpose,
we're
planning
eventually
to
develop
an
attestation
extension
for
this.
We're
not
ready
to
specify
it
right
now,
but
we're
leaving
this
extensibility
point
in
the
protocol
for
future
use.
G
Yeah
so
so
this
is
basically
all
of
the
interesting
changes
in
this
drop.
So
so,
to
recap
again
to
big
changes.
One
is
the
negotiation
of
the
token
binding
protocol
version
using
TLS
style
and
a
negotiation
and,
secondly,
the
use
of
extended
key
material
instead
of
detail
as
unique
any
any
questions
about
the
drafts.
Any
questions
about
the
changes
that
were
made
I.
F
Haven't
thought
this
through
so
I'll,
just
put
it
out
there,
we've
in
TLS
we've
been
moving
towards
having
signatures,
have
a
contact
string
associated
with
them
that
is
fed
in
I.
Think
the
I
think
you
know.
So
you
look
at
one
point.
Three
signatures
said
he
wrote
a
loss,
blah
blah.
I
think
that
the
exporter's
does
that
job,
but
unless
you
think
it
doesn't
it
I
just
wanted
to
raise
it
in
case
you
thought
I
didn't
do
that
job
I
mean
I,
it's
Harvey,
given
you're
gonna
have
to
do
it
anyway.
F
F
B
Who
here
has
read
any
of
the
versions?
A
relatively
recent
version
right
I
would
like
to
get
a
few
people
on
the
record
promising
to
do
like
a
review
on
the
list,
because
I
think
we
need
to
do
that
and
then
we
can
sort
of
demonstrate
that
we've
gotten
good
enough
review,
so
we
can
actually
start
to
sort
of
move
towards.
You
are,
though,
you're
volunteering
yeah,
okay,
Martin,
you
have
Jeff
toni-ann
Decker.
B
Can
you
just
put
that
in
the
notes,
because
we're
going
to
hold
you
to
it
and
just
sort
of
post
something
on
the
list?
I'm
minute
go
ahead
and
say:
any
kind
of
review
is
good,
but
the
more
authorial,
basically
the
better
and
I
and
you're,
probably
going
to
revise
one
more
time
after
that.
You
know
like.