--- Begin Message ---
- To: Russ Allbery <rra@stanford.edu>
- Subject: Re: Implications of Debian OpenSSL flaw for MIT PKINIT
- From: Ken Raeburn <raeburn@MIT.EDU>
- Date: Fri, 16 May 2008 13:28:24 -0400
Yeah, it looks worse than I thought.
If I understand correctly, though, it's not the Kerberos session key
itself that's generated via DH, it's the key used to protect the AS-
REP message, isn't it? (And it's not required to be produced via DH,
but that is the mandatory-to-implement approach, and the default in
the MIT code.) But the ability to decode the AS-REP gets you the
session key.
The terminology in RFC 4556 looks a little confusing; it refers to a
"session key" in at least one place when it appears to be referring to
the key protecting the AS-REP enc-part field, which normally would be
the principal's long-term key. (Maybe that's common usage from the
PKI world?)
On May 16, 2008, at 12:52, Russ Allbery wrote:
> The TGT session key itself is only used for requesting additional
> tickets in the most common case, however, correct? So normally this
> flaw would not expose, for instance, GSSAPI sessions, since the client
> would use the TGT to request a service ticket and the session key in the
> service ticket would be generated by MIT Kerberos's random number code
> and hence not be subject to this vulnerability?
But it gets conveyed in encrypted messages protected only by a
compromised key. So if all of the traffic is recorded, the other keys
would be exposed as well. The attacker does have to get the AS
exchange and the TGS exchange(s) and, if subsession keys are used, the
initial exchange of GSSAPI tokens, in order to compromise the GSSAPI
session.
As we have no support for perfect forward secrecy, it all hinges on
the privacy of the initial exchange with the KDC. Lose that, and the
rest comes down like a row of dominos.
Ken
--- End Message ---