The art of negotiation and trust in IPSEC

[Guest]

So if I have an XP machine, and it tries to communicate with a server. If that server wants to talk IPSEC and initiates a negotiation - will the XP machine respond and negotiate? Even if it has no explicit policies defined

I guess it comes down to trust, yes

You have to trust another computer to even BEGIN to negotiate, is that correct

And this is done by 1 of 3 methods (Kerberos, certificate, or shared secret)

Perhaps I've answered my own question. Is there an easy way to deploy certficiates via AD or without AD (scripting, file copying deployment - or does it have to be registerd)

I suppose that's enough questions for one post

Thanks in advance

Hans

 

[Steven Umbach]

The XP/W2K will not respond with secured ipsec unless it has at least the
client/respond policy enabled in security policy. Kerberos is used within a
forest as the machine authentication method for ipsec. You can easily distribute
machine certificates in an AD domain if you have an Enterprise Certificate
Authority for the domain. You can even use Group Policy to autoenroll computer
certificates in W2K. When not in a domain it becomes more difficult and involves
Web Enrollment after the offline ipsec template is enabled. See links below for
more information. --- Steve

http://www.microsoft.com/windows2000/techinfo/planning/security/ipsecsteps.asp
http://www.microsoft.com/WINDOWS2000/techinfo/planning/security/autocertsteps.asp
http://support.microsoft.com/default.aspx?scid=kb;en-us;253498

So if I have an XP machine, and it tries to communicate with a server. If

that server wants to talk IPSEC and initiates a negotiation - will the XP
machine respond and negotiate? Even if it has no explicit policies defined?

I guess it comes down to trust, yes?

You have to trust another computer to even BEGIN to negotiate, is that correct?

And this is done by 1 of 3 methods (Kerberos, certificate, or shared secret).

Perhaps I've answered my own question. Is there an easy way to deploy

certficiates via AD or without AD (scripting, file copying deployment - or does
it have to be registerd)?

 

[Guest]

Thanks for the links

To clarify, if I have two machines that are not members of any Domain, and they have IPSEC enabled via a the security policy (client/respond) - so will the machines be able to talk IPSEC with each other

Or do they still need to have a 3rd party (Active Directory or Cert. Auth (or preshared key)) to authenticate/validate the enpoints of the IPSEC conversation

So what I want (in my imaginary world) is to have two machines talk IPSEC with a third party or prior knowledge of each other

What do you think?

Thanks much in advance for the advice and info

Han


----- Steven Umbach wrote: ----

The XP/W2K will not respond with secured ipsec unless it has at least th
client/respond policy enabled in security policy. Kerberos is used within
forest as the machine authentication method for ipsec. You can easily distribut
machine certificates in an AD domain if you have an Enterprise Certificat
Authority for the domain. You can even use Group Policy to autoenroll compute
certificates in W2K. When not in a domain it becomes more difficult and involve
Web Enrollment after the offline ipsec template is enabled. See links below fo
more information. --- Stev

http://www.microsoft.com/windows2000/techinfo/planning/security/ipsecsteps.as
http://www.microsoft.com/WINDOWS2000/techinfo/planning/security/autocertsteps.as
http://support.microsoft.com/default.aspx?scid=kb;en-us;25349

So if I have an XP machine, and it tries to communicate with a server. I

that server wants to talk IPSEC and initiates a negotiation - will the X
machine respond and negotiate? Even if it has no explicit policies definedcertficiates via AD or without AD (scripting, file copying deployment - or doe
it have to be registerd)

 

[Steven L Umbach]

They can communicate with ipsec security, but at least one will need to be
configured with the request or require policy. I suggest you test with a
request policy first and monitor the results with ipsecmon to see if
security associations for ipsec AH/ESP are being established. Since you are
not in a domain you must configure your policies to use a common preshared
key or certificates. Preshared keys work well, but the preshared key is
stored in clear text which is good for testing or in situations where the
computers are physically secured or otherwise secured, but should not be
used in actual situations where high security is required. Many of the
popular vpn endpoint routers use a preshared key for ipsec tunnels. ---
Steve

Thanks for the links!

To clarify, if I have two machines that are not members of any Domain, and

they have IPSEC enabled via a the security policy (client/respond) - so will
the machines be able to talk IPSEC with each other?

Or do they still need to have a 3rd party (Active Directory or Cert. Auth

(or preshared key)) to authenticate/validate the enpoints of the IPSEC
conversation?

So what I want (in my imaginary world) is to have two machines talk IPSEC

with a third party or prior knowledge of each other.

 

[Steven Umbach]

They would need to be ipsec certificates or possibly machine certificates as
described in KB article below. I don't have experience with stand alone CA -
only enterprise. However both certificates must chain to a "trusted" Certificate
Authority. In other words in a W2K environment, it would work fine if all the
certificates were issued from any CA as long as the certificate being presented
for machine authentication is issued from a CA that the target machine trusts
such as is the case when you want to set up a ssl session with a website, their
certificate must be issued from a CA that your computer trusts and it works that
way for both ends of the connection for ipsec since it is mutual
authentication. You can view the trusted CA's via the mmc certificate snapin for
computer for ipsec. You can import a W2K CA's certificate in to a computer
trusted CA store by either by first exporting it to a .cer file and then
importing or using Web Enrollment to request it. In Active Directory, the
Enterprise CA is trusted by all domain members.

http://support.microsoft.com/default.aspx?scid=kb;en-us;253498

A computer does not need to contact a CA before engaging in ipsec
communications. However it may want to check a published Certificate Revocation
List periodically to check for any revoked certificates. I am not sure how that
is set up in a non AD computers, though I believe that the CRL can be retrieved
via Web Enroll on non AD machines. However according to the information in the
second link below, CRL checking is disabled by default for ipsec. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;313281
http://www.microsoft.com/technet/tr...prodtechnol/windows2000serv/howto/ipsecwt.asp
http://www.microsoft.com/technet/tr...indows2000serv/evaluate/featfunc/pkiintro.asp

Right, preshared = bad... bad preshared. So that leaves me with two last questions.

Great, so say we go with certificates. What kind do they have to be? They

can obviously be from the Microsoft 2000 CA - what type are they (X.509) or
should they be?

Once the machines have Certs, do they need to contact the CA before talking

IPSEC to confirm the validity of the Cert on the remote endpoint? (Much like in
a scenario when a user goes to an SSL enabled website, they must ask the 3rd
party (Verisign) whether the Cert from the web server is kosher (so to speak)).
Or can we get by without ANY communication to the CA? (After the Cert is
deployed.)

Your help has been most appreciated and very helpful! I have been reading

around other posts (before I posted) but the question of trust and how it works
isn't discussed much. I very much like the FreeSWAN idea of 'opportunistic
encryption' - if only that was a reality now.