Re: IPSEC wireless router ?
- From: lynn@xxxxxxxxxx
- Date: 25 Sep 2005 12:33:53 -0700
David Taylor wrote:
> It's not new Duane. All you're doing is blocking traffic by port. I'm
> surprised that it's new to you.
>
> The main advantage of IPSec is the Sec part, i.e. security. Simply
> creating filters and a filter action like you are doing is the very
> simplest start. What the original poster wanted was security which to
> do properly requires a PKI implementation. Then you get mutual
> authentication and encryption, none of which you have right now.
at a 94 IETF meeting in the gateway working group ... a friend
introduced something that has since come to be called VPN. my view was
that it somewhat upset the ipsec people ... since they were working on
end-to-end. the issue with ipsec has been that it required updates to
all the deployed (mostly kernel) tcp/ip protocol stacks. VPN could be
deployed w/o impacting current installed systems. eventually things
were somewhat patched over with the ipsec people labeling VPNs as
light-weight ipsec ... and lots of other people referring to ipsec as
heavy-weight ipsec. there was at least one vendor who announced a
purely vaporware vpn product that dec. ... in response to the uptake of
the concept after the ietf meeting.
to a large degree, the apperance of SSL was because of the same factor
.... the difficulty with doing end-to-end ipsec because of its
impacting, existing deployed systems.
towards the end of 94, my wife and i got called in to cpmsult with the
small client/server company that had come up with ssl ... who wanted to
do payments on their server
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
at the time, they had this stuff that was going to use something called
digital certificates issued by these organizations called certification
authorities (as part of something called PKI). as part of doing
payments ... we had to go around and do some end-to-end business audits
on these organizations calling themselves certification authorities ...
some collected postings on the subject off SSL certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert
SSL implementation at the time was one-way authentication between the
server and the browser. using SSL for the webserver to payment gateway
traffic ... we required an SSL implementation that supported mutual
authentication.
however, as part of that effort, we coined the term "certificate
manufactoring" ... since the majority of the operations weren't
actually doing full-fledge PKIs ... no actual management and
administration of the certified information (contained in the digital
certificates) ... just the straight-forward manufactoring of the
certificates. In fact, numerous certificate-based infrastructures from
the period would rely on existing business operations for
administration of the current validaty of the certified information (as
opposed to actually deploying a full-fledge PKI). The issue then was
that for such operations ... it was quite a trivial proof to show that
the digital certificates were redundant and superfluous (if you were
relying on existing business operations for real-time validity ... then
it was a very short step to having existing business operations also
providing public keys in real time).
there is now even cross-over between the original 94 vpn and the 94 ssl
.... with the apparance of ssl-based VPNs.
the basic technology is asymmetric key cryptography; what one key (of a
key-pair) encodes, the other key decodes (to differentiate from
symmetric key which uses the same key for both encoding and decoding).
there are business process applications of asymmetric key cryptography
called "public key" (where one key is identified as public and made
available, and the other key is identified as private and kept
confidential and never divulated) and "digital signature" (which
involves encoding a hash of a message/document with a private key).
However, there are numerous examples of infrastructures that use public
keys, digital signatures, encrypted channels that don't involve PKI,
certification authorities, and/or digital signatures.
one of the most prevalent authentication infrastructures is RADIUS ...
starting out having been a userid/password implementation. There have
been extensions to RADIUS where public keys are registered in lieu of
passwords and digital signatures used for authentication ... totally
certificateless operation
http://www.garlic.com/~lynn/subpubkey.html#radius
another wide-spread authentication environment is KERBEROS, found as
integral part of a large number of platforms. the original pk-init
specification had public keys being registered in lieu of passwords and
supporting digital signature authentication ... again a certificateless
operation
http://www.garlic.com/~lynn/subpubkey.html#kerberos
pk-init specification was later upgraded to also include PKI and
certificate-based operation ... supporting the ability for total
strangers to log on to your system ... recent lengthy description
http://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Signature
another public key, non-PKI authentication and confidential
infrastructure with relatively wide deployment is SSH
http://www.openssh.com
http://www.ssh.com
in any case, IPSEC PKI infrastructure can carry with it a much heavier
infrastructure operation than is actually needed for public key
authentication and encryption (and even can be redundant and
superfluous compared to simple upgrades to existing management and
administrative operation).
http://www.garlic.com/~lynn/subpubkey.html#certless
.
- Follow-Ups:
- Re: IPSEC wireless router ?
- From: Jeff Liebermann
- Re: IPSEC wireless router ?
- References:
- Re: IPSEC wireless router ?
- From: David Taylor
- Re: IPSEC wireless router ?
- From: Duane Arnold
- Re: IPSEC wireless router ?
- From: David Taylor
- Re: IPSEC wireless router ?
- Prev by Date: Re: DI-624 opinion
- Next by Date: CBQ - Wireless
- Previous by thread: Re: IPSEC wireless router ?
- Next by thread: Re: IPSEC wireless router ?
- Index(es):
Relevant Pages
|
