►
From YouTube: IETF92-KITTEN-20150327-1150
Description
KITTEN meeting session at IETF92
2015/03/27 1150
A
A
B
A
So
today's
agenda
will
take
as
we're
getting
through
the
five
minutes
here
to
go
through
the
preliminaries,
then
we'll
go
over.
A
working
group
document
status
will
cover
the
Kerberos
pad
deprecating,
old,
Kerberos
and
corporate
encryption
with
the
then
and
then
Nico's
going
to
present
I'd
leave
the
remaining
items
on
this
list.
Does
there
anything
else
you
wanted
to
try
to
cover,
as
it
is
I
think
we
might
end
up
going
over.
A
C
A
A
D
Emery
yeah,
so
I
think
the
consensus
on
the
list
was
that
the
Security
section
security
considerations
section
that
had
the
sins
about
the
denial
service
attack
for
long
streams.
I
think
that
was
a
pretty
much
consensus
as
far
as
removing
that
statement,
since
we
believed
it
wasn't,
a
legitimate
concern
is
that
do
you
agree
with
that
statement?
D
Nico,
okay
for
the
PRF
draft
Arbus
graph
there
there
was
a
sentence
in
the
security
considerations
section
that
mentioned
that
without
impact
integrity,
protection
that
the
views
large
strains,
long
strings,
that
I
could
be
used
as
a
denial
service
before
integrity,
protection
and
I
think
we
agree
that
that
that
was
not
a
particular
issue.
Okay,
so
I.
B
B
A
We've
got
60
120
6112
this,
the
Annette
bah
I
can't
speak
anonymity
sport.
So
this
again,
this
is
probably
number
three
of
those
bits
documents
that
went
out
to
working
group
last
call
simultaneously.
There
is
some
edits
needed,
we're
not
sure
if
a
new
last
column
need
be
issued.
That's
going
to
end
on
how
extensive
those
edits
are.
We
are
also
again
soliciting
volunteers
to
take.
Take
that
work
on
yeah.
D
C
D
A
C
So
the
the
original
Gia
GSS
Java
bindings
were
quite
a
while
ago
and
it's
hard
to
get
a
sense
from
the
the
mail
archives
in
the
minutes
about
what
people
were
actually
thinking
at
the
time.
So
I
guess
really.
The
question
is
you
know,
does
anybody
in
the
room
have
an
opinion
about
the
Java
binding
sneak
ova
standing
up?
So
I
guess
we
should
hear
from
him.
E
My
opinion
is
that
the
the
stream
stuff
should
go,
but
it's
not
terribly
important,
whether
it
goes
or
not.
The
my
impression
is
not
that
the
original
authors
felt
that
the
API
could
do
all
the
wire
encoding
yeah
for
the
application,
but
rather
that
one
would
create
a
stream
out
of
a
single
token
and
say
here's
a
stream
for
you
to
consume.
E
That's
my
impression,
so
it's
not
important
if
it
stays
or
if
it
goes
there
is.
There
is
one
organization
that
actually
uses
self
framing
tokens
and
that's
the
GSI
folks
they
have
a.
They
have
a
mechanism
that
speaks
TLS
and
because
TLS
is
self
framing.
If
you
just
put
the
tokens
on
the
on
the
wire
without
any
additional
framing,
you
have
a
GSS
interface
to
TLS
right.
C
E
No,
no,
it
doesn't
have
a
length
and
and
the
the
the
asn.1
little
header
with
the
oid.
That
was
only
in
all
tokens
in
RFC,
1964
and
41-21.
We've
removed
it
from
the
per
message
tokens.
So
not
even
that
is
present,
so
41-21
is
not
self
framing,
but
TLS
is,
and
so
one
could
in
fact
use
this.
The
way
people
thought
this
was
intended
to
be
used,
but
I
think
it
was
intended
to
be
used
as
here's
a
stream
containing
a
single
tooth
can
three
or
produces.
C
A
C
A
E
C
B
A
So
then
we
also
have
a
number
of
documents
that
we
don't
believe
are
yet
ready
for
working
group
last
call
I,
believe
we
yeah
so
sam'l
EC
Scott
has
been
very
busy,
so
there
hasn't
been
any
extra
prop.
There
hasn't
been
any
progress
other
than
the
new
verte
version
posted
in
December.
We
are
wondering
if
anybody
has
read
this
document
yet
one
hand.
Okay,
so
reviews
of
this
would
be
very
useful
if
anybody
would
please
work
on
those,
then
we've
got
iono
curb
curb.
A
This
is
ben
post
an
update
in
october
again,
have
we
had
anybody?
That's
read
it
shawnigan
all
right,
okay,
so
we
do
need
some
more
review
and
comment
to
help
us
figure
out
if
there
are
more
edits
or
if
we
really
are
ready
to
put
this
into
the
queue
of
documents
to
push
forward
to
working
group.
Last
call.
E
Yeah,
this
came
up
recently
on
one
of
herb
dev
about
negotiation
issues
with
negotiating
mechanisms
that
you
don't
know
might
succeed
and
how
that
might
affect
protocols
where
you
really
have
to
succeed
or
I'll
see.
You
have
a
bigger
problem
and
it
occurs
to
me
that
we
should
have
a
mechanoid.
This
is
nikko.
We
should
have
a
mechanism
attribute
for
indicating
that
this
is
one
of
those
mechanisms
that
you've
no
idea
might
succeed,
because
there
are
applications
that
really
don't
want
to
try
mechanism
that
might
not
succeed.
E
A
A
Now
we
got
just
two
biss
need
to
update,
so
there's
sired
update
just
respect
to
allow
for
mechanisms
that
don't
have
the
ability
to
do
a
mutual
author
channel
binding
there's
a
number
of
comments
and
the
on
the
list
they
haven't
been
addressed.
We
would
need
some
help
for
somebody
to
go
through
the
list,
try
to
find
what
these
are
and
gather
them
up
at
one
time,
Alexia
volunteered
make
updates.
F
F
A
A
A
There
is
there's
currently
no
way
to
incrementally
upgrade
an
application
from
no
bindings
using
them
without
a
flag
without
a
flag
day.
Strapped
has
been
expelled,
expired
for
quite
a
while
I
can't
remember
what
the
date
was
so
yeah
it.
So
is
there
still
interest
in
trying
to
move
forward
on
this
so.
E
I
I
am
interested
in
moving
forward
on
this,
but
I
don't
have
cycles
for
for
a
little
while.
So
if
you're
willing
to
wait
a
couple
of
months,
I
can
pick
it
back
up.
Well,
I'm,
not
sure
that
the
current
state
is
is
correct
and
so
I
actually
need
some
help.
Thinking
through
it,
because
it's
falling
out
of
my
cash.
B
E
B
C
A
So
now
we've
got
on
the
next
up:
we've
got
to
pee
Cana
algorithm
agility,
thus,
updates
begin
it
to
remove
structures
tied
to
particular
algorithms
in
favor
of
negotiation,
where
this
document
did
expire
in
2012.
So
there
is
desire
to
do
future.
We
do
believe,
there's
future
proofing
necessary
in
the
feet.
Eventually
bill
had
volunteers
had
volunteered
to
edit,
but
chairs
have
dropped
ball
and
what
changes
were
actually
needed.
I
think
we
finally
got
in
the
source
which
took
some
doing,
and
then
we
kind
of
lost
track
of
where
we're
going
from
there
yeah.
A
A
D
C
Yeah
I
got
I
got
a
mail
from
Tom.
That
says
he
thinks
we
can
probably
get
it
taken
care
of
by
the
next
IETF
meeting,
or
maybe
the
one
after
that,
but
who
would
like
some
help,
setting
up
sort
of
intermediate
milestones
so
that
we
don't
have
a
huge
giant
task
that
we
try
to
do
all
at
once,
but
we
can
break
it
up
into
smaller
pieces.
So
we
can
probably
take
that
to
the
list.
A
A
E
Eco
here
Aleksei
mentions
the
TLS
unique
channel
binding,
but
it
you
know
the
possibility
that
it
needs
to
be
replaced.
But
the
thing
that
really
needs
to
happen
is
that
TLS
needs
a
session,
a
cryptographic
session
ID,
which
is
what
one
of
the
drafts
for
the
TLS
working
group
does
and
TLS
13
will
have
that
and
once
you
have
that
we
can
either
use
that
session
hash
or
use
the
existing
TLS
unique.
It
doesn't
change
in
its
specification,
but
the
hash
draft
takes
care
of
adding
the
missing
binding
internally
in
TLS
yeah.
F
E
Don't
know
how
hard
it
would
be
to
deploy
a
new
channel
binding
type
also,
what
we
would
have
to
do
effectively
to
do
it
right
is
to
say
you
have
to
have
the
session
hash
extension,
and
then
you
have
to
use
that
as
the
channel
binding.
That's
so
one
way
or
another
you're
going
to
have
to
have
the
session
hash
thing.
So
if
the
idea
is
to
to
make
progress
without
13,
TLS,
123
out
I,
don't
think
that's
going
to
happen.
E
C
F
C
C
Okay,
oh
good,
we
can't
fit
the
entire
slides
up
there,
so
I
am
been
one
of
your
co-chairs.
Simo
is
not
here,
but
simo
had
wanted
to
talk
about
the
pad
concept,
and
you
know
to
some
extent
draft
so
I
said
I
was
familiar
enough
with
it
to
to
be
able
to
talk
about
it.
So
you
know
sort
of
the
background
is
that
POSIX?
It
was
sort
of
a
single
OS
instance.
Spec
no
talks
about
the
local
identity
information,
but
the
plastic
standard
doesn't
talk
about
remote
systems
or
remote
identity
and
whatnot
information.
C
C
So
this
concept
that
we
came
up
with
several
years
ago,
I
think
before
I
was
even
involved.
Was
this
ability
to
put
the
POSIX
profile
in
the
off
data
in
a
Kerberos
ticket?
And
so
then
you
know
the
OS
if
it
trusted
the
KDC.
Would
be
able
to
populate
the
group
information
and
similar
things
just
from.
B
C
Kerberos
ticket-
that's,
it
is
already
using
for
authenticating
user,
but
course
you
need
the
information
to
be.
You
know,
secure
and
and
authenticated
that
the
KDC
has
actually
issued
it,
even
if
you
can
only
perform
some
of
these,
these
lookups
about
the
the
authorization
data
at
the
initial
authentication,
and
so
that
means
that's.
You
know
that
this
pad
extra
POSIX
data
might
be
coming
back
to
the
KDC
from
other
service
tickets
multiple
times,
and
so
we
really
need
the
hammock
container
is
superior
to
like
the
KDC
issued
container
for
the
sort
of
data.
C
So
like
basically,
your
people
I,
think
history
I
think
the
history
is
that
people
started
wanting
the
pad,
they
realized
they
needed
to
cam
ACK
and
they
start
working
on
the
cam
back
and
we've
only
just
now
finished
the
cam
acts,
so
we
can
start
getting
back
to
thinking
about
the
pad,
so
yeah
I
mean
usually.
This
would
be
something
that
you
populate
and
generate
at
the
initial
authentication
when
you
get
the
TGT,
but
you
could
also
do
some
modification
if
you
need
to
next
slide.
C
So
the
use
cases
for
this
and
understanding
is
that
seem.
Has
actually
had
customers
coming
in
and
asking
for
this
sort
of
thing,
so
there
might
be
applications
that
can
handle
Kerberos
tickets,
but
they
don't
necessarily
know
how
to
get
to
the
ldap
server
or
whatever
server
you're.
Using
for
these,
these
extra
user
data-
you
know-
or
there
could
be,
a
network
topology
issue.
There
could
be
cross
Rome,
setups,
they're,
sort
of
similar,
where
the
relying
Kerberos
server
just
simply
cannot
talk
to
the
the
user
data
server.
C
Id
number
group
ID
home
directory
shell
information-
that's
actually
typo,
it's
not
twenty,
thirty,
seven,
but
2307,
which
is
that
scheme
out
for
this
sort
of
stuff,
and
you
can
have
you
the
group,
memberships,
multiple
groups
and
sort
of
the
the
origin
of
where
the
groups
are
you.
If
you
have
Kerberos
principles
from
multiple
different
realms,
you
could
have
those
consolidated
into
a
single
group,
namespace
and
still
track.
C
You
know
which
original
realms
are
from
next
slide
and
then
there's
optional
yeah
you
can
have
you
know
if
there
are
alternate
usernames
or
identifier
is
nickname,
though
maybe
the
nickname
is
in
the
geckos
I
forget
that
just
Ruth
other
things
that
might
be
useful,
but
are
not
you
always
necessarily
going
to
be
present
and
I
guess
we
could
be
flexible.
So
if
there's
a
case
where
you
don't
actually
have
a
POSIX
compliant
new
group
server
or
group
information,
we
could
also
come
up
with
something
to
accommodate
that
within
the
pad.
C
We
would
not
necessarily
be
strictly
tied
to
the
POSIX
concepts.
I
think
there's
one
more
slide,
yeah.
So
there's
this
old
draft,
which
is
long
expired,
which
is
from
the
original
discussions,
but
we
would
definitely
be
modifying
it.
We're
not
entirely
sure
exactly
what
modifications
those
would
be.
It
would
certainly
be
changes
to
like
the
pros
text
and
possibly
to
the
to
the
protocol
all
data
structures
as
well.
Oh.
E
This
is
nikko,
so
the
the
UID
S&G
ids
really
need
to
be
qualified
with
with
a
point
of
origin,
and
there
could
be
multiple
ones.
So
this
starts
looking
like
SIDS
with
a
little
bit
of
compression
and
that's
fine
and
it's
good
and
the
NFS
people
might
actually
care
for
this.
There's
a
draft
for
you
know
Federation
for
NFS
before
which
would
it
this
would
be
very
useful.
There
remember
that
the
UID
zingia
these
are
really
all
local
to
something
they're,
all
local.
E
So
when
you're
dealing
with
someone
else's
local,
you
IDs
in
you
have
to
have
some
sort
of
mapping
and
in
many
cases
for
one
domain
when
I
one
source
identifier,
the
mapping
will
be
an
identity
function,
but
for
others
will
be
something
else,
and
this
exists
in
various
implementations.
So
you
really
need
that
source
identifier
and
you
need
to
be,
and
especially
as
across,
realms
and
add,
or
remove
some
of
these
group
memberships.
You
need
to
be
able
to
to
identify
the
source
of
each
of
them.
Ok,
so
you
think
so.
The.
C
E
E
Possibly
yeah
because
a
lot
of
environments
tend
to
have
multiple
unix
domains
or
whatever,
where
for
one
reason
or
another,
they'll
have
diff.
You
know
different
assignments
of
the
same
new
IDs
and
JDS
and
then,
but
they
only
really
have
one
realm
and
its
historical
you
have
to
deal,
but
also,
even
if
k
identifier
is
the
realm
right.
As
you
cross
realms-
and
you
add
group
memberships,
perhaps
right
each
KDC,
maybe
add
some.
You
really
are
crossing
namespace
boundaries.
If
you
really
really
have
to
have
this
unavoidable,
ok,
I
guess.
C
B
B
D
E
You
go
well.
First
of
all
there
I
PR
I,
you
know
I
I,
don't
know
anything
about
it,
so
I
could
only
speculate,
but
if
the
IPR
is
about
carrying
this
kind
of
data
in
your
tickets,
then
you've
lost
already
the
moment.
You
want
to
carry
it
another
thing
by
the
way
that
I
wanted
to
rewind-
and
mention
is
it's.
This
is
a
very
nice
network,
optimization
for
your
directory
servers.
It's
a
very,
not
nice
network,
optimization
for
everything
else,
because
you're
carrying
these
big
tickets
now
where
they
should
have
been
smaller.
E
So
one
of
the
extensions
that
I'm
proposing
for
multiple
round
trips
allows
the
service
to
give
you
a
smaller
ticket
in
exchange
for
your
big
one
right.
It's
kind
of
session
resumption
for
TLS,
so
you're
again
I
want
that.
But
then
the
last
pessimism
that's
involved
here
is
people
tend
to
have
fairly
long
live
tickets.
All
right
TGT
is
at
least
and
of
course,
oh.
You
got
added
to
a
group
that
you
need
to
log
in
again
or
you
know,
oh,
you
got
you
got
removed
from
a
group.
E
You
know
we
need
to
find
a
way
to
revoke
all
your
tickets,
so
these
are
problems
that
come
up
when
you
start
using
this.
This
you
know
carrying
your
authorization
data
on
your
tickets.
On
the
other
hand,
there
are
use
cases
where
this
is
really
the
only
way
right.
As
you
mentioned,
there's
there
are
services
that
will
not
have
access
to
ldap,
and
so
so
we
really
need
something
but
but
yeah
as
far
as
the
IPR.
B
C
We
have
another
presentation
and
I
will
stay
up
here:
okay,
so
yes,
deprecating
rc4
and
Triple
DES
for
kerberos
very
exciting,
so
I
named
the
death.
The
draft
des
des
des
night
I
died
because
it's
fun
name
greg
was
saying:
maybe
it
should
have
been
arc
for.
Please
go
away.
Maybe
it's
not
quite
so
urgent
as
single
des
was,
but
maybe
not
you
know
there
are
these
persistent
rumors
about
RC
for
vulnerabilities
that
we
don't
have
any
concrete
data
on
so
I.
Don't
really
know.
C
C
C
C
Ignore
the
bullet
point
about
GSS
channel
bindings
I
was
confused
when
I
was
reading
the
slides,
but
you
know
in
some
sense
they're,
both
starting
to
get
weak
and
our
experience,
getting
rid
of
single
deaths
has
shown
us
that
it
really
does
take
a
long
time
to
get
people
to
stop
using
these
things.
So
we
should
start
soon.
Maybe
we
should
started
five
years
ago.
B
C
So
I
guess
tying
very
closely
into
that.
One
of
the
reasons
to
get
rid
of
our
c4
is
that
the
string,
the
key
function
is
really
really
bad.
So
if
you're
not
using
our
c4
estrena
key
function.
In
that
Sarah
scenario,
that's
interested
so
Chris
the
string.
The
key
function
is
unsalted
md4,
so
you
have
a
single
rainbow
table
for
all
users
in
all
realms
and
you
can
populate
that
rainbow
table
very
quickly.
C
And
so
that's
why
the
lack
of
the
salt
came
into
play
and
the
sort
of
funky
unicode
stuff,
and
so
with
the
anti
password
hash.
Apparently
there
are
some
some
ways:
some
scenarios
in
which
an
application
server
ends
up
with
anti
password
hash.
If
it's
doing
aunty
LM
protocol
and
then
it
happens
to
have
the
Kerberos
key
as
well,
and
that's
a
really
nasty
cross
protocol
attack.
I
do
not
know
the
details
of
that.
If
you
do
know,
scenarios
in
which
that
happens,
please
pipe
up.
C
I
would
love
to
hear
about
it
and
have
more
text
in
the
draft
and
sighs
we
sort
of
alluded
to
this
already,
but
you're.
Getting
rid
of
varsity
four
is
going
to
be
hard
because
it's
in
some
of
these
old
windows
systems,
windows,
XP
windows,
server,
2003,
the
systems
only
support
single
des
rc4.
Luckily
they're
going
yo
el
real
soon
now,
but
the
other
sort
of
related
issue
with
these
windows
systems.
C
If
you
have
cross
Rome
trusts
that
were
generated
back
with
the
windows,
server
2003,
those
are
still
going
to
be
the
rc4
keys
and
redoing
the
cross.
Rome
trust
is
there's
the
cross.
Rome
key
is
still
pretty
challenging.
Nikos
I
think
going
to
be
talking
about
related
issues
later
on
and
they're
probably
other
reasons
why
getting
rid
of
it
will
card
I,
don't
know
what
they
are
right
now,
I'm
happy
to
hear
more
and
flush
out
the
draft
Oh,
so
the
moving
on
to
Triple
DES
Triple
DES
is
not
quite
as
bad
as
rc4
again.
C
B
C
The
birthday
attack
after
to
the
32
encryptions,
some
people
might
worry
about
that.
Some
people
might
not.
The
ciphertext
collision
would
just
be
revealing
like
a
couple
blocks
of
plaintext.
It
would
not
be
a
full
compromise
which
you
would
get
you
know
with
some
of
the
AED
modes
if
you
reuse
an
oz,
so
it's
not
too
bad.
Triple
DES
is
also,
of
course,
very
slow,
but
those
are
so
the
main
complaints,
and
so,
if
I'm
expecting
any
pushback
on
this
proposal,
I'm
sort
of
expecting
here,
because
you
know
Triple
DES-
is
perhaps
not
super
bad.
C
So
maybe
we
don't
need
to
start
deprecating
it
right
now.
I
personally,
still
think
that
we
should
start
the
process
because
it's
going
to
take
a
while,
but
you
know
I'm
happy
to
hear
from
people
who
think
otherwise,
because
you
know
Microsoft
never
implemented
air
ball,
Microsoft
Ripton,
implementation
of
Triple
DES
as
far
as
I
know,
so
we're
really
talking
just
the
UNIX
implementations
and
if
you're
deploying
anything
new,
it's
going
to
be
able
to
do
a
s
as
well
as
Triple
DES.
The
next
slide
so
yeah,
that's
all
I've
got
for
the
presentation.
C
B
C
Can
be
both
so
the
Kerberos
protocol
and
well
I
guess
the
encryption
type
profile
requires
you
to
provide
a
string
to
key
function
for
generating
keys
from
passwords
and
also
a
random
to
key
function
or
just
turning
random
data
into
I.
Think
for
well
feel
our
seafaring
type.
The
random
takia
is
just
the
identity
function,
but
the
string
dequeue
function
does
take
a
password
input
right.
B
C
C
B
E
E
E
It's
a
no-go
because
of
of
the
use
of
long-term
keys,
where
we
can
really
provide
enough
assurances
as
to
IV
non
reuse
and
generally
I,
be
reused
for
for
a
Dieng
types
is
fatal
to
security,
so
the
only
places
where
we
can
really
use
these
the
cipher
modes
is
in
session
key
context
or
we're
using
a
session
key
and
the
obvious
one
is
GSS.
There
aren't
really
any
Kuro
supplications,
not
very
many
that
use
the
curve
prive
and
curved
safe
messages,
PD
use.
So
we
don't
really
need
this
for
kerberos
in
general.
E
We
only
really
need
it
for
GSS.
This
fits
perfectly
into
41-21.
It's
a
very
small
modification.
The
only
question
really
for
me
is:
should
we
share
an
n-type
namespace?
Where
should
we
define
another
type?
Negotiation
payload
for
for
GSS,
right
and-
and
this
is
a
bit
tricky
here-
because
of
the
way
egg
type
selection
is
is
handled
in
the
egg
type
negotiation?
Really
it's
the
server
sending
back
a
nap
wrap
encrypted
in
the
egg
type
that
that
it
shows
from
the
egg
tech
negotiation
payload.
So
obviously
there
would
be
some
impact
on
Kerberos,
but
anyways.
C
I
mean
just
in
turn,
Benkei
doc,
just
in
terms
of
the
n-type
namespace
registry,
there's
already
a
bunch
of
egg
types
in
there
which
are
not
which
have
very
serious
limitations
on
what
context
to
Allah
to
use
them
in
right,
yeah,
I
guess.
Maybe
some
people
think
that
was
a
mistake,
but
I
haven't
heard
anybody
being.
E
Able
strong
use
the
existing
egg
type
namespace
is
convenient.
It's
just
a
little
less
work
to
do.
We
would
still
need
a
new
app
track
message.
Rex
are
a
prep
message
with
a
new
field
or
or
accessibility,
or
something
by
which
the
server
can
indicate
that
yeah.
This
is
the
egg
type
we're
going
to
be
using
sure.
C
E
E
E
The
next
thing
is
Kerberos
is
a
one
round-trip
protocol
or
really
a
half
round
trip
and
a
one-run
trip,
and
it
doesn't
handle
error
recovery
very
well
at
all.
So
if
you,
your
ticket,
your
service
ticket
is
just
expired
or
not
valid.
Yet
or
you
have
skew
clock,
skew
issues
or
any
number
of
things
this.
Perhaps
the
server
got
rekeyed,
perhaps
yeah
yeah.
Any
any
number
of
issues
like
this.
C
E
E
E
And
I'd
like
to
see
it
adopted,
or
else
Shep
hurted,
but
this
is
this-
is
very
desirable
in
some
environments,
so
yeah
I
think
I've
described
in
the
story.
There's
also
the
our
cash
avoidance.
It
also
gets
your
user
to
user
right.
You,
you
get
a
ticket
or
even,
if
you
don't
really
have
a
ticket,
you
got
the
the
KDC
told
you.
Oh,
this
guy
can
only
do
use
your
user.
E
While
you
send
a
bogus
initial
context
token,
the
service
says:
hi,
you
can
do
multiple
round
trips
and
here's
my
TGT
that
you
need
to
use
for
forgetting
a
user
or
user
bingo.
You
got
user
user.
This
also
handles
our
cash
avoidance.
In
some
ways
you
you
know,
we
need
to
make
sure
that
the
initial
context
token
can't
be
replayed
against
some
other
service,
that's
also
using
the
same
long-term
keys,
but
but
other
than
that.
This
handles
on
replay
cash
avoidance.
E
Replay
caches,
are
really
really
hard
to
get
right
and
in
a
clustered
environment,
extremely
difficult
to
get
right.
Some
of
the
stuff
I've
seen
on
0r
Kiki
data
and
the
TLS
working
group
has
me
very
concerned
because
you
know
Kerberos
has
been
trying
to
use
a
replay
cash
for
decades
and
it's
not
really.
None
of
the
implementations
have
really
gotten
it
right.
B
D
To
that
respect,
Shanna,
Marie
I
think
this
yeah
would
be
very
helpful.
You
know,
like
I,
said,
a
lot
of
the
applications.
The
services
are
moving
away
from,
you
know
shared
shared
services.
Luckily,
there's
you
know
a
few
windows
2000
clients
around
there,
but
in
case
I,
think
this
is
a
issue,
a
major
issue
that
we
find
and
usually
the
void
ensuite
play
cash.
Corruption
is,
you
know,
just
to
put
a
lock
around
the
acceptor,
which.
E
Did
you
know
a
while
back
I
did
some
work
on
avoiding
you
know
the
need
for
F
sinks
and
so
on
and
that
improved
our
cache
performance
greatly,
but
there
were
still
many
ways
in
which
they
are
cash.
In
the
standard,
solaris,
sorry
Kerberos,
implementations
out
there
are
just
no
good
right.
The
our
caches
are
are
just
really
really
hard
to
get
right.
So
we
need
to
do
this.
E
Fortunately,
for
a
lot
of
applications,
it's
kind
of
a
non-issue
all
the
applications
where
the
client
says
the
first
per
message:
token,
if
you're
using
newegg
types,
RFC
41
to
the
one
in
times
it
just
works
out,
if
you
don't
have
an
hour
cash,
but
it's
an
accident
right.
So
it's
a
happy
accident.
We
should.
We
should
do
something
about
it.
E
The
cases
where
we
know
that
this
is
this
is
okay
like
there
are
no
non-accidental
happiness
cases,
then
we
don't
need
additional
round
trips,
but
anyways
next
slide,
then
there's
PK
cross
manual,
cross-realm
rekeying
keying,
is
terrible.
Some
implementations
don't
even
have
multiple
key
sets
for
principle
and
manual
cross
from
key
role
over
necessarily
results
in
breakage,
and
so
you
have
to
turn
your
ticket
lifetimes
down
a
lot
to
try
to
avoid
that
that
this
doesn't
solve
that,
but
it,
but
still
it's
a
manual
process.
E
The
operators
learn
the
keys,
it
doesn't
scale,
it's
it's
one
of
the
biggest
problems
with
kerberos
scalability
next
slide,
and
so
the
rough
idea
is
basically
get
a
get
a
certificate
for
your
from
your
local
realm
ouching
for
your
identity.
And
then
you
go
dhoop
ek
in
it
at
a
remote
realm.
So
it's
not
really
PK
in
it
anymore
and
if
you
add
a
little
bit
of
Dane,
we
can
actually
that
build
peek
across
that
scales.
You
know
web
scale,
yeah,
there's
I'll
go
back
for
a
bit.
E
There
is
there's
ways
to
do
a
percent
to
persist
such
a
peek
across
key
cross-realm
trust.
There's
ways
to
do
it
where
you,
the
keys,
are
ephemeral
right
and
there's
ways
to
do
it,
where
the
clients
do
all
the
work
and
there's
ways
to
do
it
where
the
TGS
is.
Do
all
the
work
for
clients
that
don't
support
it
has
some
privacy
features
that
are
desirable,
I
think
it
would
be
good
next
and
then
there's
name
attributes,
there's
there's
a
variety
of
name
attributes
that
we'd
like
to
have
some
of
them
can
be
generic.
E
There
are
things
like?
Oh
the
pier
you
know,
your
peers,
a
host
based
service
and
here's
the
service
and
here's
a
hostname,
and
this
is
the
issuer.
The
issuer
could
be
a
CA
name,
x-p
kicks
name
or
it
could
be
a
Kerberos
realm
or
it
could
be
any
number
of
other
things.
Trust
validation,
path
should
be
available.
A
variety
of
things
should
be
available
for
users,
of
course,
user
name
and
local
names,
local,
username,
right
and
so
on.
Is
there
another
slide?
That's
it!
Ok,
there
are
other
things
that
I
didn't
put
on.
E
This
slide
are
the
the
impersonation
attribute,
which
is
a
way
of
saying
I'm
using
this
disk
Kerberos
principle
that
really
has
no
known
no
access
to
any
no
authorization
to
anything
except
two
other
two
small
number
of
other
services
to
those
services.
It
can
impersonate
anybody
right.
This
is
for
middleware.
So
it's
so
no
need
for
financial
delegation
no
need
even
for
constraint,
credential
delhi,
because,
as
for
you
has
issues
with
cross
realm,
you
can't
loop
back
to
your
home
realm
and
in
some
environments.
E
That's
a
problem
with
this
impersonation
attribute
when,
when
a
middleware
thing
wants
to
impersonate
someone
to
someone
else,
it
just
basically
acquires
a
credential
for
itself,
but
with
this
impersonation
attribute
for
its
name,
saying
I'm
impersonating
this
other
person
and
this
works
safely,
because
if
the
service
is
trying
to
impersonate
to
doesn't
understand
this,
it's
just
going
to
see
the
middleware
principal
name,
which
is
not
really
authorized
to
anything.
If
it
does
understand
it,
it's
going
to
extract
the
attribute
set.
E
Oh
you're,
impersonating
Niko,
and
you
know
I'm
just
going
to
check
that
you
are
authorized
to
do
this
and
there
we
go
right.
So
it's
very
lightweight
impersonation,
very,
very
lightweight
credential
delegation.
If
you
like,
no
no
credential
evaluation
and
then
there's
the
pad
stuff
right
accessing
access
to
to
come
back
to
payloads
the
Cadillac
accesses
to
parts
of
the
pad.
Those
are
no
longer
generic,
but
we
need
to
actually
do
that
too,
and
actually
they
would
be
generic
in
some
sense
right,
just
because
it's
only
Kerberos
carrying
those
things
doesn't
make
them
Kerberos
specific.
E
C
Yeah
so
then
there's
this
McCallum
kitten
curb
service
discovery.
We
had
some
discussion
on
them
on
the
list
about
this.
This
is
sort
of
like
a
new
year
I
scheme
for
using
dns
lookups
to
find
Kerberos,
Casey's
and
similar
services
to
potentially
replace
the
existing
serve
records
and
reduce
the
number
of
DNS
queries.
You
need
so
I
guess
you
know.
Hopefully,
people
have
been
following
lists
and
unseen.
This
I
just
want
to
check
if
anyone
had
comments
they
want
to
make
at
the
mic
about
it.
C
E
C
E
C
E
C
C
Yeah,
so
we're
just
gonna
go
through
all
them
asking
who's
read
or
yours
familiar
so
who
has
read
the
pad
or
thinks
they
know
what
it
is
for.
People
who
has
read
the
des
des
des
die
die
die
a
few
more
who
has
read
the
group
five
extra
round
trip
just
to
you,
the
GSS.
Only
ink
types,
I
think,
was
just
Nico's
mail,
but
who
read
that
mail.
C
The
generic
naming
attributes
who
read
that
we're
looking
at
the
same
handful
of
people
here,
the
chorus,
the
Kouros
service
discovery.
I
read
that
I
read
that.
Actually,
I'm
not
sure
that
again,
two
to
three
people,
the
impersonation
naming
attributes
I,
who
read
that.
But
just
two
people
I
didn't
read
that
and.
A
D
D
C
D
C
B
But
yes,
I,
but
I
got
up
to
suggest
is
maybe
means
you
mean
it.
You
know.
The
energy
level
in
this
working
group
has
been
my
ongoing
thing,
but
still
people
keep
managing
to
do
good
work,
just
not
at
a
tremendously
high
pace,
but
that's
that
that's
okay,
I
mean
I
would
suggest.
Maybe
it
not
just
asking
who's
interested,
but
you
try
and
prioritize
them.
I
mean
some
solemn.
B
E
E
Yeah,
which
well
for
my
own
registrations,
which
is
probably
not
good,
no
so
we'd,
have
to
find
someone
else
to
be
a
reviewer
for
that,
but
I'm
sure
we
could
so
at
least
three
of
these
atoms
could
go
that
way
and
and
the
the
die
die
die.
One
I
think
you
know
I
think
that
one
should
be
a
really
easy.
E
One
right
I
mean
listing,
the
attacks
is
not
necessary,
like
being
extremely
thorough,
is
nice,
but
if,
if
that's
a
problem
in
terms
of
energy
for
reviewing
look,
everybody
knows
single
des
is
not
a
good
idea
and
our
c4
is
not
a
good
idea.
So
just
basically
tell
people
to
stop
doing
it
and
that's
easy
enough
move
move
some
bits
of
perhaps
do
the
RFC's
1964
biz.
That
is
really
41-21,
plus
the
missing
bits
and
just
just
drop
1964
to
historic,
but
I
don't
know
PK
cross.
E
Perhaps
the
easiest
way
to
deal
with
that
one
is
implement
and
let
you
know
let
people
use
it
and
if
two
years
downline
people
actually
want
to
standardize
it
we
could
write.
So
that's
you
know
that
that
one
I
think
doesn't
necessarily
need
to
be
adopted.
The
only
ones
that
really
need
to
be
adopted
in
terms
of
review
from
the
working
group
are
the
service
discovery,
extra
round
trip
and
GSS
only
n
types.
Those
are
not.
There
is
no
other
way
to
do
those
I,
don't
think
so.
E
C
E
Do
that
because
I
didn't
know
if
people
would
think
it
was
a
bad
idea,
so
so
I
thought
that
impersonation
attributes
perhaps
needed
some
review,
but
I
think
it's
also
fairly
obvious
right.
So
it's
it's!
You
can't
use
it
by
accident.
If
you're
using
it,
you
should
be
using
it
on
with
a
credential
that
that
really
has
no
authorization
other
than
to
do
this,
with
spits
with
specific
peers
right.
So
I
think
that
one
definitely
goes
in
generic.
Finally,
the
last
thing
I
would
say
is
the
generic
naming.
Attributes
is
a
very
nice
way.
E
E
If
you
want
to
provide
applications
with
access
to
something
a
little
simpler,
then
here's
a
certificate
chain
and
you
go-
have
your
own
asn.1,
pickax
parser
thing
that
that
be
handy
right.
So
one
of
the
attributes
is
yes,
I
validated
it
up
to
a
trust,
anchor
and
here's
the
trust
anchor
or
perhaps
you
could
set
a
trust
anchor
on
your
on
your
acceptor
principal
or
your
initiative.
E
Okay,
I
think
that
might
make
it
more
more
desirable
as
a
working
group
item
them,
but
the
tls
people,
for
example,
are
very
busy
right
now
anyway,
so
I,
don't
think
they'll
care,
but
if
we
then
decide
that
we
care
and
someday
we'll
plug
it
at
them,
maybe
we
should
make
it
a
working
group
item.
I,
don't
know.
A
All
right
so
I
guess
next
steps
on
this
one
is
the
chairs
and
possibly
our
ID
will
discuss,
which
ones
we
can
start
bringing
in
I
mean
what
I
will
note
that
we've
got
also
ooh
this
list
of
documents
that
still
need
to
even
even
go
through
so
I
mean
sure
but
I'm
just
saying
just
saying
that
I
mean
there's
a
number
of
documents
in
the
queue
to
prep
for
working
group.
Last
call
that's
an
awful.
This
is
an
awful
lot
of
work,
but
we
can.
A
B
A
A
B
Have
one
thing
stayed
entirely
so
I
Sean,
as
he
indicated
I
think,
was
the
plan-
was
that
you
guys
kind
of
clear
to
go:
/
sean
Sam,
first
invention
or
transitioning
out,
so
I
think
sean
has
decided.
Now
is
the
time
to
lose
the
dot,
and
so
thanks
to
him
for
all
his
work
over
the
years,
and
thanks
to
you
guys
for
kind
of
picking
up
and
taken
over
in
doing
so
well
in
the
meantime.
So
thank
you,
sean
yeah.
Yes,
thank
thank.