Archived from groups: comp.security.firewalls (More info?)

Can certificates be added to a firewall Running Checkpoint NG 55
without configuring the firewall? I would like to add certificates to
a firewall, but I don't want to configure the firewall (IP Addresses,
netmasks, hostname, etc. etc.)

Thanks!

Archived from groups: comp.security.firewalls (More info?)

The question is...what is a certificate's main function?

The answer is...to uniquely identify the bearer of the certificate

The problem is...I would like to add certificates to
a firewall, but I don't want to configure the firewall

The answer is...No, Your identity (online) is tied to your IP address, if
you change your IP address, you will need to renew your certificates. If you
do not provide an IP address, you have not satisfied the requirement, having
an IP address, which is needed to certify the source, your identity.

"Pedro Cortez" <nomada7@hotmail.com> wrote in message
newsb72fc7c.0405260732.e2cd802@posting.google.com...
> Can certificates be added to a firewall Running Checkpoint NG 55
> without configuring the firewall? I would like to add certificates to
> a firewall, but I don't want to configure the firewall (IP Addresses,
> netmasks, hostname, etc. etc.)
>
> Thanks!


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.688 / Virus Database: 449 - Release Date: 5/18/2004

Archived from groups: comp.security.firewalls (More info?)

"Beoweolf" <Beoweolf@pacbell.net> writes:
> The question is...what is a certificate's main function?
>
> The answer is...to uniquely identify the bearer of the certificate
>
> The problem is...I would like to add certificates to
> a firewall, but I don't want to configure the firewall
>
> The answer is...No, Your identity (online) is tied to your IP address, if
> you change your IP address, you will need to renew your certificates. If you
> do not provide an IP address, you have not satisfied the requirement, having
> an IP address, which is needed to certify the source, your identity.


basically a certificate is to bind some information to a public key,
typically for use in an offline environment.

typically somebody generates a digital signature, appends a certificate
and transmits it.

the receiver eventually gets the transmission, uses the certificae to
verify the digital signature and then has some comfort that the
transmission is somehow related to the information bound in the
certificate. the type of information bound in the certificate might be
identity or even permission related.

the typical business process has the receiver looking up some online
account record for the information instead of with a certificate.

certificates had a design point from the early '80s for offline email
.... the environment where somebody dialed up their "post office",
exchange email, hung up and processed the email offline. the
certificate was designed to serve an introductory function when the
recipient had never previously had any communication with the sender.

the function of the certificate was to serve as a substitute, in an
offline electronic environment of the early 80s, for access to the
real information. In a firewall scenario ... the lack of RADIUS-like
function being able to access the real information.

the x.509 identity certificate standards (somewaht from the early 90s)
started to run into problems by the mid-90s because of the enourmous
privacy issues related to having potentially enourmous amounts of
privacy related information flying around in such certificates.

Somewhat in an attempt to preserve the certificate paradigm and
demonstrate some marginal utility for certificates ... there was some
effort to retrench the x.509 identity certificate to something called
a relying-party-only certificate ... which basically contained only an
account number and a public key. Some financial operations
demonstrated such an implementation in conjunction with various
payment related operations.

There was some serious issues with this mode of operation.

1) it was trivial to show that in such a relying-party-only
scenario; the certificate was redundant and superfluous. by definition
if you have to access the account record with all the real
information, then the certificate doesn't actually contain any useful
information, making the existance of the certificate redundant and
superfluous. it also violates the basic assumptions of the certificate
design point, a substitute in an offline environment for access to the
real information.

2) even relying-party-only certificates could get to fairly large,
nominally in the 4kbyte to 12kbyte range. in the payment attachment
scenario; the typical payment message is 60-80 bytes, containing the
account number and the amount of the transaction. In the
relying-party-only scenario a 128byte digital signature would be
attached to the payment message followed by the digital certificate.
This is sent to the relying-party financial institution that has all
the information in an account record (including a copy of a public
key). The destination financial institution pulls the account number
from the payment transaction, reads the account record, retrieves the
public key and verifies the digital signature. At no time did it need
to resort to referencing the certificate. So in an attempt to
demonstrate some marginally utility for a relying-party-only
certificate, append a certificate that need never be used but does
increase the payload bloat of a typical payment message by
approximately one hundred times.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Archived from groups: comp.security.firewalls (More info?)

Beoweolf wrote:

> The question is...what is a certificate's main function?
>
> The answer is...to uniquely identify the bearer of the certificate
>
> The problem is...I would like to add certificates to
> a firewall, but I don't want to configure the firewall
>
> The answer is...No, Your identity (online) is tied to your IP address, if
> you change your IP address, you will need to renew your certificates. If
> you do not provide an IP address, you have not satisfied the requirement,
> having
> an IP address, which is needed to certify the source, your identity.

I don't know where you got that idea, but it just doesn't work that way.

A certificate is a third party confirmation of your NAME, not your address.
Thus a server certificate (which is probably what the OP was asking about)
simply confirms that the server www.serv.com really is www.serv.com. What
the IP address is has nothing to do with this: that is the job of the DNS.

Look up the definition of the certificate fields for X509.

As to "adding certificates to the firewall" - the question is meaningless. A
firewall has no certificates, nor does it use them. A certificate is almost
always connected to an application (Web server, EMail server, proxy,
browser, EMail client, VPN, etc), so you need to look for the documentation
for those.
--
Mailman

Archived from groups: comp.security.firewalls (More info?)

Mailman <mailman@anonymous.org> writes:

> I don't know where you got that idea, but it just doesn't work that
> way.
>
> A certificate is a third party confirmation of your NAME, not your
> address. Thus a server certificate (which is probably what the OP
> was asking about) simply confirms that the server www.serv.com
> really is www.serv.com. What the IP address is has nothing to do
> with this: that is the job of the DNS.
>
> Look up the definition of the certificate fields for X509.
>
> As to "adding certificates to the firewall" - the question is
> meaningless. A firewall has no certificates, nor does it use them. A
> certificate is almost always connected to an application (Web
> server, EMail server, proxy, browser, EMail client, VPN, etc), so
> you need to look for the documentation for those. -- Mailman

domain name server certificates exist because of trust issues with the
domain name system and am I really talking to the server I think that
I'm talking to.

basically 3rd party certificatation authority is asked to certify that
i'm really the owner of the domain name and issue a certificate to
that effect.

the client types or clicks on a URL ... the browser goes off and
contacts the server, the server sends back a certificate ... the
browser checks to see if it is a valid certificate (using a table of
certification authority public keys that have somehow been loaded into
the browser at some time) and then checks to see if the domain name in
the certificate matches the typed or clicked on value. so one of the
exploits is to get the user to click on a field that actually points
to a domain name that matches a certificate that a bad guy might
happen to have.

now, the 3rd party certification authorities ... in order to certify
somebody is really the domain name owner ... have to contact the
authoritative agency for domain name ownership; which turns out to be
the domain name infrastructure ... this is the same entity that people
supposedly have trust issues with and therefor believe they need
certificates.

now, 3rd party certificate authorities have some trust issues and
process issues with domain name infrastructure also ... there happen
to be a number of proposals to improve the integrity of the domain
name infrastructure ... some of them being backed by the 3rd party CAs
(if people can't trust the source of the information for the certified
infomration, how can they trust the certificate).

one of these proposals somewhat from the 3rd party CA industry,
involve a domain name owner registering a public key with the domain
name infrastructure at the same time they register their domain name.
Future interaction between the domain name owner and the domain name
infrastructure can involve digital signatures that can be validated
with the registered public key ... minimizing things like domain name
hijacking and various other exploits. So this improves the reliance
and trust that the 3rd party CA industry places in the domain name
infrastructure.

the other issue is that the 3rd party certification process is fairly
expensive identification process. the current paradigm has the domain
name owner registering a bunch of identity information with the domain
name infrastructure. when the domain name owner applies for their
server certificate, they also provide a lot of identification
information. The 3rd party CA than has an expensive and error prone
process matching the presented identification information with the
identification information on file with the domain name
infrastructure. With a public key on file with the domain name
infrastructure, the domain name owner can just digitally sign a
certificate request. the 3rd party CA then just has to retrieve the
public key on file and verify the digital signature. This changes an
expensive and error prone identification process into a much simpler,
less error prone, and less expensive authentication process.

So there is something of a catch22 for the 3rd party certification
industry.

1) If the integrity of the domain name infrastructure is improved,
then the lack of trust supposedly will be lowered, which likely also
results in lower demand for certificates.

2) if there is a public key on file with the domain name
infrastructure (for the domain name owner) that the 3rd party
certification process can retrieve for authentication ... then
presumably other entities, like end-users and clients might also be
able to retrieve the public key for performing authentication
.... eliminating the requirement for needing digital certificates
issued by a 3rd party certification authorities.

misc. past posts on ssl server certificates
http://www.garlic.com/~lynn/subtopic.html#sslcert

note that general case of using the domain name infrastructure for a
public key server (w/o needing certificates) shows up in some of the
anti-spam proposals for authenticating email senders.

part of the issue is that that the domain name infrastructure is
actually a distributed, near-real-time, information distribution
mechanism. it is currently primarily used to distribute the ip-address
related to a specific domain or host name. however, the domain name
infrastructure has also been used for serving up other kinds of
real-time data. There is nothing that prevents the domain name
infrastructure from also serving up real-time public keys that are
bound to a domain or host name.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Archived from groups: comp.security.firewalls (More info?)

Mailman (mailman@anonymous.org) wrote:
: Beoweolf wrote:

: > The question is...what is a certificate's main function?
: >
: > The answer is...to uniquely identify the bearer of the certificate
: >
: > The problem is...I would like to add certificates to
: > a firewall, but I don't want to configure the firewall
: >
: > The answer is...No, Your identity (online) is tied to your IP address, if
: > you change your IP address, you will need to renew your certificates. If
: > you do not provide an IP address, you have not satisfied the requirement,
: > having
: > an IP address, which is needed to certify the source, your identity.

: I don't know where you got that idea, but it just doesn't work that way.

: A certificate is a third party confirmation of your NAME, not your address.
: Thus a server certificate (which is probably what the OP was asking about)
: simply confirms that the server www.serv.com really is www.serv.com. What
: the IP address is has nothing to do with this: that is the job of the DNS.

: Look up the definition of the certificate fields for X509.

: As to "adding certificates to the firewall" - the question is meaningless. A
: firewall has no certificates, nor does it use them. A certificate is almost
: always connected to an application (Web server, EMail server, proxy,
: browser, EMail client, VPN, etc), so you need to look for the documentation
: for those.
: --
: Mailman

In the context of the original question it is not meaningless. In the Checkpoint
arena the management server also functions as a certificate authority for enforcement
modules. A checkpoint firewall most certainly does have certificates and makes
extensive use of them. The firewall will not function with the cert.

Now, the original question asked was could one add certificates to a checkpoint firewall
without configuring it. The answer is no. The certificate is created when the firewall
object is created and the internal communications tab is press. At that time you have to
enter a one-time password that will be used to download the certificate. In order to
have the process start, the firewall object must be configured so the extent that it
has a name and at least one interface is routable from the enforcement module and the
management server. You do not have to fully configure the interfaces ro anything
else on it.

You then use cpconfig on the enforcement module to reset SIC and enter the same one time
password. If both sides can see each other [the default policy loaded on the enforcement
module has the UDP port used for SIC open] they will use the one time password to validate
each other and the managment server will push the certificate for the enforcement module
down to it. When that happens, SIC is running and uses the certificate to verify the
connection. The cert is not tied to IP but to the name of the firewall object and the
name of the management server object. If either of these change, you have to re-initialize
SIC on both sides [which revokes the old certificate].

Richard H. Miller, MCSE, CCSE+
Information Security Manager
Information Technology Security and Compliance
Information Technology - Baylor College of Medicine