Re: The art of negotiation and trust in IPSEC

From: Steven Umbach (n9rou_at_n0spam-comcast.net)
Date: 02/14/04 

Date: Sat, 14 Feb 2004 02:25:46 GMT

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/treeview/default.asp?url=/technet/prodtechnol/windows2000serv/howto/ipsecwt.asp
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windows2000serv/evaluate/featfunc/pkiintro.asp

"Hans" <anonymous@discussions.microsoft.com> wrote in message
news:183A6CB3-1C04-456B-B4D2-45EB91A25C97@microsoft.com...
> 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.
>
> Now it comes down to testing out various scenarios I suppose.
>
> Thanks much,
>
> Hans
>
>
> ----- Steven L Umbach wrote: -----
>
> 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
>
>
>
> "Hans" <anonymous@discussions.microsoft.com> wrote in message
> news:D600754A-CFD0-4626-ADF7-248EF927FD41@microsoft.com...
> > 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!
> >> Hans
> >>> ----- Steven Umbach wrote: -----
> >> 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
> >>> "Hans" <hej107us@yahoo.com> wrote in message
> > news:D0C7BAEE-B7D9-4F80-B708-99347B66FA00@microsoft.com...
> >> 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
> >>>

Relevant Pages

  • Re: IPSEC wireless router ?
    ... > The main advantage of IPSec is the Sec part, ... digital certificates issued by these organizations called certification ... SSL implementation at the time was one-way authentication between the ... supporting digital signature authentication ... ...
    (alt.internet.wireless)
  • Re: IPSEC with non-domain Server
    ... Certificates are not the "most secure", rather, they are one of the 2 "more ... > authenticate computers and protect traffic integrity and confidentiality ... > Attacks on IPSec and Other Security Concerns ...
    (microsoft.public.security)
  • Re: Shared Certificate Store in Active Directory
    ... There is no need to store IPSEC certs in the AD for IPSEC, ... > Active Directory so you can make Certificates and their ... > Certificates rather than Kerberos? ...
    (microsoft.public.win2000.security)
  • Re: freeswan: no reply packets / nat
    ... > local access to a client or server. ... Ipsec uses certificates. ...
    (comp.os.linux.security)
  • Re: SSL and Client Authentication
    ... First I go on my client and I do a browser request from a CA, ... After issuing a cert. ... install (where I verify that this certification was installed ... > It definitely does not sound like the right way to do client certificates. ...
    (microsoft.public.inetserver.iis.security)