[Top][All Lists]

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

Re: TGS revisited

From: Simon Josefsson
Subject: Re: TGS revisited
Date: Fri, 28 Apr 2006 10:37:31 +0200
User-agent: Gnus/5.110005 (No Gnus v0.5) Emacs/22.0.50 (gnu/linux)

Elrond <address@hidden> writes:

> On Thu, Apr 27, 2006 at 10:53:23PM +0200, Simon Josefsson wrote:
>> Elrond <address@hidden> writes:
>> >> > w2k3-kdc is still not liking us. :-|
>> >
>> > Okay, here's my current point of interest in this part:
>> >
>> > Changing shishi to use plain md5 for rc4-hmac makes
>> > w2k3-kdc send a TGS-REP (ethereal sees it).
>> Oh, then I think we are pretty close.  You may not need to test the
>> patches.
> The patch to remove the subkey helped.

Interesting...  but I'm not sure I understand fully yet:

> shishi with one -v told me lots of times, that it had
> problems decrypting the received ticket (TGS-REP).
> So I guess, the w2k3-kdc encrypts the ticket using the
> sent subkey or exactly not (whatever shishi doesn't like).
> At least ethereal couldn't decrypt the with-subkey version
> either.
> After adding the subkey patch, both (shishi and ethereal)
> could decrypt the received ticket.

The thing is that shishi should, because heimdal gets this wrong, try
to decrypt the TGS-REP using first the subkey and then the ticket key.
So even if etherreal isn't able to decrypt it, shishi should have
(unless w2k3 encrypts it to a bogus key).

I can understand if w2k3 reject the request completely if a subkey is
used, but that wasn't the case here?  W2k3 did responded with a
TGS-REP when shishi sent a TGS-REQ with a subkey?

Can etherreal decrypt the TGS-REP when you talk to a heimdal KDC, and
you send a subkey?  If that is the case, I would guess that w2k3 gets
confused by subkeys and encrypts it to some garbage key instead of
either the ticket key or the subkey.

> This all with rc-hmac4:plain-md5.
> :hmac-md5 comes tomorrow.

I'd be surprised if it makes a difference.

> I have no idea, what the specs says about TGS-with-subkey. ;)

It's explicitly permitted, see section 3.3.3:

   The ciphertext part of the response in the KRB_TGS_REP message is
   encrypted in the sub-session key from the Authenticator, if present,
   or in the session key from the TGT.  It is not encrypted using the

I think we are close to both understanding and solving this problem.
I think we should forward the details to the KRB-WG once my questions
above are answered.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]