[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Fwd: Implications of Debian OpenSSL flaw for MIT PKINIT

Here is the confirmation and analysis from upstream, forwarded with
permission.  Another person (not publicly, so I won't mention his name
just in case he didn't wish to be mentioned) also pointed out that since
you can break the encryption used to protect the TGT, you can also then
use that Kerberos TGT to obtain further tickets until it expires (which in
the Kerberos world is usually some locally-configured time period between
eight hours and two weeks, usually on the shorter end of that range).

Any sessions started via a Kerberos TGT issued by a vulnerable Kerberos
KDC should be considered suspect, although the key space isn't, I believe,
quite as small as it is for some of the other affected software.
--- Begin Message --- 
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 ---
Reply to: