That is my understanding of it.
 
Machine A connects to Machine B. Machine A produces its TGT to get a service ticket for B. Machine B produces its TGT to get a service ticket for A. That's all that is necessary for the IPsec layer.
 
-nh


From: sandy s [mailto:sandypossible@gmail.com]
Sent: Thursday, December 08, 2005 8:40 PM
To: Nathan Herring
Cc: ipsec-tools-devel@lists.sourceforge.net; ipsec-tools-users@lists.sourceforge.net
Subject: Re: [Ipsec-tools-devel] Problem of racoon and GSS API.

Hi Nathan

Thanks a lot for that quick reply. I have some questions with respect to your reply.

The IPsec level sits at a different level than the rest of it -- you may end up performing two different sets of Kerberos authentication in these cases: (1) The client contacts the KDC to acquire a service ticket for ike/machine@REALM (or whatever your principal looks like for IPsec -- ours are machine$@REALM) and this is used for establishing the IPsec connection. (2) The client then performs networking operations, accessing the server's services over that IPsec connection, and this (may) require a second service ticket (depending on what service it is), e.g., http/machine@REALM. I write "may," because on Windows networks, you can access SAMBA (NetBIOS) shares using the same service ticket as for IPsec (machine$@REALM), though cifs/machine@REALM is also supported for the same access.

>> In the new ipsec-tools 0.6.3 , ike has been removed. It now uses host/fqdn as principal. I am looking in to machine based authentication between the MIT client which is will use either  MIT based KDC or  microsoft DC acting as  KDC. I am not really bothered about the application services. So in this scenario, my understanding is one service ticket per system will be sufficient. Could you please if this is correct ?

Probably not. If you are trying to test out your IPsec connection using telnet and you don't have a telnet service turned on, then nobody would be listening on the port to try and open a connection in the first place. However, you can use ping (icmp) to test it without the application services running.
>> I put the question in such a way that It got a different meaning :-(  I am sorry for that. My intention of this question was, I need not bother about the application services on the service side since I am interested only in IPSec authentication which happens for machine level rather than per service. Is my understanding  correct ?     

Thanks,
Sandy.


On 12/9/05, Nathan Herring <nathanh@microsoft.com> wrote:
Comments inline.


From: sandy s [mailto:sandypossible@gmail.com]
Sent: Thursday, December 08, 2005 8:00 PM
To: ahasenack@terra.com.br; a.kasparas@gmc.lt; vanhu@free.fr; Nathan Herring; ipsec-tools-devel@lists.sourceforge.net; ipsec-tools-users@lists.sourceforge.net
Subject: Re: [Ipsec-tools-devel] Problem of racoon and GSS API.

Hi,

Thanks a lot for all the replies. I was not able to use racoon to do a kerberos auth based IPsec connection :(

I  wanted to use this setup to see what credentials are getting aquired by client and server when GSS API based kerberos is used for IPSec.

Could anybody please let me know if :
I am connecting from a system which is acting as a client  to another server. Assume that the system which is acting as server has many application servers running such as telnet, ftp, dns, dhcp etc.  Then If I use IPSec using kerberos,  do I need service  tickets for all these services ?  Or Do I need only one ticket for the server system. I assume machine based authentication will happen rather than service based authention. Am I correct ? 
 
Correct. The IPsec level sits at a different level than the rest of it -- you may end up performing two different sets of Kerberos authentication in these cases: (1) The client contacts the KDC to acquire a service ticket for ike/machine@REALM (or whatever your principal looks like for IPsec -- ours are machine$@REALM) and this is used for establishing the IPsec connection. (2) The client then performs networking operations, accessing the server's services over that IPsec connection, and this (may) require a second service ticket (depending on what service it is), e.g., http/machine@REALM. I write "may," because on Windows networks, you can access SAMBA (NetBIOS) shares using the same service ticket as for IPsec (machine$@REALM), though cifs/machine@REALM is also supported for the same access.

In this case, I need not bother about the application services running. Right ?  
 
Probably not. If you are trying to test out your IPsec connection using telnet and you don't have a telnet service turned on, then nobody would be listening on the port to try and open a connection in the first place. However, you can use ping (icmp) to test it without the application services running. 

Could you please help me ?

- Sandy.