[Fwd: Re: authentic man in the middle]

[Nikhil Mishra]

Any help is appreciated .

-------- Original Message --------
Subject: 	Re: authentic man in the middle
Date: 	Tue, 24 Feb 2009 23:35:52 +0530
From: 	Nikhil Mishra <nikhilm at gs-lab.com>
To: 	jaltman at secure-endpoints.com
CC: 	krbdev at mit.edu, kerberos at mit.edu
References: 	<49A3CE64.4020804 at gs-lab.com>
<49A42677.5060601 at secure-endpoints.com>



Thanks Jeffrey.

I am fine with the limited lifetime part . I completely understand
the solution will be unstable enough to be useful. Nevertheless
I still need a tool to  retrieve long term service keys to  see
what is being said below is true .
 
I will move this discussion to kerberos at mit.edu.
My apologies for the trouble.

Thanks

Nikhil

Jeffrey Altman wrote:
> Nikhil:
>
> The problem you are facing is that you do not control the
> key management of the Windows Domain.  Windows services
> do not use fixed keys.  They use long term passwords that
> are assigned to each account and which are then used with
> the necessary enc-type and service principal name to compute
> the appropriate key on-the-fly.  This permits an account to
> have multiple names all of which do not need to be known
> at account registration time.  For example, a mobile machine
> that obtains a different hostname at each boot and registers
> it with dynamic dns which in turn updates the machine's
> entry in the active directory.
>
> The passwords are also periodically updated.  Therefore,
> even if you were to extract the machine's password from
> the registry its lifetime would be limited.  You would
> have to do it again whenever the password was replaced.
>
> As a side note, this discussion really has nothing to do
> with the development of MIT Kerberos.  Therefore, it is
> my opinion that it should be held either on the kerberos at mit.edu
> mailing list or one of the Windows Security Groups.
>
> Jeffrey Altman
> Secure Endpoints Inc.
>
> Nikhil Mishra wrote:
>   
>> Hi All,
>>
>> We have an issue with generating a valid keytab for windows based
>> services which can be used on unix based machines to decrypt AP-REQ.
>> I understand this issue is more on windows side but since I am trying
>> to implement sort of man in the middle on MIT kerberos I think 
>> someone could lend me some helping hand here.Any related references
>> might also do some good to me.-
>>
>>  
>> Following is our setup :
>>
>> 1. Windows XP cifs client
>> 2. Windows 2003 KDC and domain controller 64 bit
>> 3. Windows XP cifs server 64 bit.
>> 4. Linux FC7 machine with MIT kerberos 1.6.3
>>
>> We have the admin privileges for all the machines mentioned above.
>>
>> What we are trying to do ?
>>
>> 1. We request a kerberized traffic from cifs client to cifs server
>>     which we want to route through linux box.
>>
>> 2. We want to do some processing with the AP-REQ.  Evidently  for
>>     which we need to authenticate the client in AP_REQ on linux machine.
>>
>> 3. Now to authenticate the client in AP-REQ on linux machine we
>>     propose to use GSSAPI calls using corresponding service keytab.
>>
>> The problem :
>>
>> 1. Our understanding is, all windows based services are registered
>>     under corresponding computer name with their corresponding SPN.
>>
>> 2. This registration occurs whenever the machine joins the domain. So
>>     basically , whenever the  server is up and running and is in domain
>>     all its services are registered with windows domain controller and
>>     are mapped to its computer name.
>>
>> 3. The exchange of long term keys for service between service and KDC
>>     occurs at the same time.
>>
>> 4. We understand the definition of ktpass is "To generate keytab for
>>     UNIX based services " but with no other option to generate a keytab,
>>     we run ktpass for this windows based service which creates a new
>>     long term service key for the service which  is not communicated back
>>     to service.
>>  
>>     When I use this keytab on linux machine through GSSAPI calls to
>>     decrypt the AP-REQ , I get KRB5KRB_AP_ERR_BAD_INTEGRITY.
>>    
>>     which is obvious since key used by KDC to encrypt the ticket for
>>     service is different(Its the old key ) than what is in keytab.
>>
>> Questions :
>>
>> 1. Is there a way to bring KDC and  service in sync in terms of the
>>     service key being used ? To be more precise , If I change the
>>     service key for a service at KDC Is there a way to communicate 
>>     this back to service so that the service starts using this new key
>>     for all further requests ?
>>
>> 2. We understand ktpass is a tool to generate a keytab for unix based
>>    services. Do we have any similar tool for windows based services ?
>>
>> 3. Since windows based service SPN's are registered under computer name
>>     at the time of logon It can be mapped to some other user as well without
>>     creating a duplicate SPN. Is it possible for a service to run under
>>     a user account and obtain a service key in windows ?
>>
>> 4. We understand "man in the middle" is not possible with kerberos but 
>>    when we own all components of traffic ( KDC , server , client , DC 
>>    with admin privileges ) should't I be allowed to extract a service key
>>    for the given SPN from KDC without disturbing the existing setup ? 
>>
>> Any help is deeply appreciated.
>>
>> Thanks & Regards
>>
>> Nikhil
>>
>>
>> _______________________________________________
>> krbdev mailing list             krbdev at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
>>