[kitten] PA-ENC-TIMESTAMP is worse than we thought; fix in aes-cts-hmac-sha2?

[Nico Williams <[e-mail]>]

draft-ietf-kitten-aes-cts-hmac-sha2 wants randomly generated salts.

That's nice, but... why did we ever have non-randomly-generated salts?

"Convenience" seems like a nice explanation, but I suspect it wasn't
just that: it may have been a half-baked security feature.

  C->AS: AS-REQ
  AS->C: KRB-ERROR w/ PA-ETYPE-INFO2 w/ a random salt
  C:     string2key() w/ the AS's salt
  C->AS: AS-REQ w/ PA-ENC-TIMESTAMP using string2key() called with the
         server's choice of salt

Do you see the problem?

What if the AS is an active attacker?  They can then use a single salt
for all clients, one that they have a computed rainbow table for.  The
victim clients will happily use this salt.

  Mallory:    <choose salt, compute rainbow table>
  C->Mallory: AS-REQ
  Mallory->C: KRB-ERROR w/ PA-ETYPE-INFO2 w/ Mallory's rainbow table salt
  C:          string2key() w/ Mallory's choice of salt
  C->Mallory: AS-REQ w/ PA-ENC-TIMESTAMP using string2key() called with
              Mallory's choice of salt
  Mallory:    <start off-line rainbow table attack on C's PA-ENC-TIMESTAMP>
              <disappear or be MITM and pass through further exchanges
               between C and AS>
              <profit>

So randomizing the salt doesn't help at all.  It makes things worse
even: clients now can't sanity check the salt.

But if the salt *must* start with an unambiguous encoding of the
client's principal name and realm, _and_ if the client checks that this
is so, then the attacker can no longer have a single raibow table for
all victims.  And we can have a random suffix in the salt to add some
additional security (especially if this suffix is changed every time the
user changes their password).

Now, PA-ENC-TIMESTAMP is just awful and we know it, and this is NOT a
new attack: RFC3962's Security Considerations describes this attack as
to the iteration count (but not the salt, but the idea follows).

Though it does feel like a new attack: it seems likely that RFC3962
would have mentioned salt spoofing in addition to iteration count
spoofing, if the authors had thought of salt spoofing...  Back then the
WG did have a chance to improve some things for "newer" enctypes, and we
did, so we might have done that for salts too, if we'd thought of it.

Anyways, we've got two ways of addressing this problem _today_, and
we're working on a third:

 - (existing) PKINIT (look ma', no passwords; but not trivial to deploy)
 - (existing) FAST tunnel (requires a bit more configuration on the clients)
 - (upcoming) SPAKE

So maybe we just don't care about this problem.

But we could perhaps plug the above hole by requiring clients to check
that the salt is prefixed with an unambiguous encoding of the client
principal's name and realm name at least when using the new AES-CTS
HMAC-SHA2 enctypes or _newer_.  (Clients should probably _not_ require
this for older enctypes, not by default, for interop reasons.)

This has some consequences for principal renames, but pretty much
nothing else, I think.  Either principal renames cannot be supported
without an administrative password reset, or the KDC must force the user
to change their password after a rename _and_ the client must prompt the
user to confirm the rename and the previous principal name (which
further means that the client must be able to extract and decode the
principal name and realm name prefix from the salt).  I think this is
mostly a non-issue.

Do we care?  Enough to fix this?  Now?  Ever?

Now's the time for the new enctypes.  If not now, never (because the
SPAKE will take care of this problem).

If we're inclined to fix this now, I'll implement for Heimdal.

Nico
--