Re: IPSEC with non-domain Server
lynn_at_garlic.com
Date: 09/22/05
- Next message: Steven L Umbach: "Re: Serial/Thumbprint of Certificate attached to CA?"
- Previous message: Joe Naughten: "RE: Computer and User Certificates Issues"
- In reply to: Steven L Umbach: "Re: IPSEC with non-domain Server"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 22 Sep 2005 14:42:55 -0700
Steven L Umbach wrote:
> If you are using ipsec for just "filtering" then no computer authentication
> is used anyhow. If you are using it for AH/ESP to authenticate computers and
> protect traffic integrity and confidentiality then you need to use a
> computer authentication method. Certificates is the most secure method and
> any Windows 2000/2003 Server can be a Certificate Authority though trusting
> your CA may be an issue depending on whether or not you have access to
> configure those computers that should be allowed access or distribute them
> the CA's certificate. The problem with pre-shared key is that it is stored
> on the computers that use it in clear text in the registry and is could be
> easily recoverable [see link below]. If you do not think that is a problem
> in your situation then it could be a viable solution and not being in an AD
> domain is a plus for its use. If you do use be sure to use a complex
> pre-shared key and change it on a regular basis. --- Steve
>
> http://online.securityfocus.com/infocus/1528
> Attacks on IPSec and Other Security Concerns
>
> There are some important security considerations to keep in mind about IPSec
> in Windows:
>
> a.. preshared keys are stored clear text in the registry, accessible by
> administrators
> b.. Active Directory stores IPSec configuration policies, and preshared
> keys in the clear,
The original pk-init draft for kerberos had public keys registered in
lieu of passwords ...
http://www.garlic.com/~lynn/subpubkey.html#kerberos
with kerberos performing digital signature validation using the on-file
public keys for "something you have" authentication.
from 3-factor authentication paradigm
http://www.garlic.com/~lynn/subpubkey.html#3factor
* something you have
* something you know
* something you are
digital signature verification is typically a form of "something you
have" authentication, aka the originator has access and use of the
corresponding private key.
basically the core technology is asymmetric key cryptography ... what
one key encodes, the other key decodes (to differentiate from symmetric
key cryptography where the same key is used for both encrypting and
decrypting)
there is a business process defined called public key ... where one of
the key-pair is identified as public and freely distributed; the other
of the key pair is identified as private, kept confidential and never
divulged. The business process of maintaining unique access and use of
the private key is the basis for claiming "something you have"
authentication.
there is a business process defined called digital siganture ... where
the originator creates a digital signature by calculating the hash of
some message/document and then encodes the hash with the private key.
The recipient (relying party) recalculates the hash of the
message/document, decodes the digital signature with the corresponding
public key and compares the two hashes. If they are the same, then the
recipient (relying party) can assume
1) the message/document has not been altered since the digital
signature
2) assume "something you have" authentication; i.e. the originator had
access to and use of the corresponding private key.
Basically recipients and/or relying parties typically create a trusted
repository of known public keys (sometimes this has been referred to as
pre-shared keys). It is these on-file public keys, that recipients can
use for validating digital signatures.
Somewhat from the offline email days, there was a business process
defined that involves PKIs, certification authorities and digital
certificates. This was to address first time communication between
strangers where the parties have no prior knowledge and/or access to
any information source about each other (i.e. the "letters of credit"
model from sailing ship days). The scenario was that the recipient
dialed their local (electronic) post office, exchanged email, hungup
and potentially faced dealing with first time email from total stranger
and had no facilities for obtaining information about the stranger.
In this scenario, the total stranger has gone to a certification
authority, registered their public key, and claimed some information
about themselves. The certification authority verifies the claimed
information and issues a digital certificate attesting to the
certification of the public key and the claimed information. The
stranger now can create a message, digitally sign the message, and
transmit the a) message, b) digital signature and c) digital
certificate.
The recipient has (hopefully) preloaded their trusted public key
repository with the public keys of some number of certification
authorities. Now instead of directly retrieving the stranger's (on
file)public key from their repository to validate the digital signature
on the message ... they retrieve the on-file public key of the
certification authority to validate the digital signature on the
digital certificate. If that digital signature correctly validates,
then they use the stranger's public key from the digital certificate to
validate the digital signature on the actual message. This is the use
of pre-shared, on-file public keys (of certification authorities) for
one level indirection to handle the case of validation digital
signatures in first time communication with strangers.
PKI and digital certificate support was added to the pk-init draft for
kerberos so that the authentication of total strangers would be enabled
for system access.
The other widely deployed authentication mechanism is RADIUS ... which
also originated in the same time-frame as kerberos and also originally
followed a userid/password model. Definitions for RADIUS operation have
also been made where public keys can be registered in lieu of passwords
and digital signature validation cane be done with the pre-shared,
on-file public keys for "something you have" authentication
http://www.garlic.com/~lynn/subpubkey.html#radius
In the early 90s, there was some direction by certification authorities
to create additional value population for x.509 identity certificates
to increase the amount of personal information. Part of this was based
on the fact that certification authorities might not know at
certification time all the possibly relying parties that might be using
the certificates in the future ... and therefor might not know ahead of
time what was all the personal information that a relying party might
need to know about an individual.
By the mid-90s, some number of institutions were starting to realize
that x.509 identity certificates grossly overloaded with enormous
amounts of personal information represented significant privacy and
liability issues. The other issue was the addition of x.509 identity
certificates on every operation, turned even the most trivial
authentication operation into a heavy-weight identification event.
Recent posts on subject of confusing identification and authentication
http://www.garlic.com/~lynn/aadsm20.htm#42
http://www.garlic.com/~lynn/aadsm21.htm#2
http://www.garlic.com/~lynn/aadsm21.htm#12
In response there was the creation of relying-party-only digital
certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
which were basically limited to the public key and some sort of
repository/database lookup index or account number (where all the real
information about the individual was kept). However, it is trivial to
demonstrate that if the relying party has all the information (included
the pre-shared, pre-registered public key) then the any appending of a
digital certificate to an authentication operation is total redundant
and superfluous.
A digital signature will be appended to a basic transaction containing
some sort of index. The relying party, pulling that record gets all the
necessary information about the signing party, including their
pre-shared, on-file public key (that can be used for validating the
digital signature).
http://www.garlic.com/~lynn/subpubkey.html#certless
one of the basic reasons for upgrading password-based infrastructure
(kerberso, radius, etc) to (pre-shared, on-file) public keys is that
passwords are shared-secret infrastructures
http://www.garlic.com/~lynn/subpubkey.html#secret
akin to symmetrical key ... where the same value is used for both
origination and authentication. being able to access the value (for
authentication or other purposes) potentially exposes the value to
leakage and use for impersonation ... where public keys are only used
for authentication.
from the security PAIN acronym
* privacy
* authentication
* integrity
* non-repudiation
a shared secret will have both privacy and integrity requirements
(although having regular access for authentication purposes can
compromise the privacy constraint). a public key basically only has
integrity requirements (by definition, it doesn't have to be kept
private and never disclosed).
- Next message: Steven L Umbach: "Re: Serial/Thumbprint of Certificate attached to CA?"
- Previous message: Joe Naughten: "RE: Computer and User Certificates Issues"
- In reply to: Steven L Umbach: "Re: IPSEC with non-domain Server"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
