Hello Irene450,
A few definitions first.
CA - Certificate (or Certification) Authority
LDAP - Lightweight Directory Access Protocol
PKI - Public Key Infrastructure
You can get a variety of definitions through
://www.google.com/search?q=define:ca
://www.google.com/search?q=define:LDAP
://www.google.com/search?q=define:pki
Several of these sites have a good summary of the related terms. Using
LDAP as an example,
http://philip.greenspun.com/internet-application-workbook/glossary
and scroll down to LDAP to get a brief explanation of one use of LDAP
(user authentication).
When you compare / contrast the use of LDAP vs CA based PKI, you will find
o LDAP is used as a general directory, retaining all kinds of
information. For example, a large company may use LDAP to store
- First, middle, and last name
- Office location including address and phone number
- Electronic addresses including email, web pages and so on
- Authentication information such as user name, password, key information
and so on.
o CA based PKI is primarily to establish a trust relationship between
two people, two companies, or an individual with a company. For
example, when I go to a secure web site such as
https://answers.google.com/answers/myquestions
to check for questions I have asked, I get an assurance from my
browser that the link established between my computer and Google's is
secure and that Google is indeed the company I have contacted.
With regard to the items you listed (issuing, storing, sending,
retrieving certificates), let's start with the fact that an LDAP
server is set up by the company or organization that is responsible
for it. There is no specific requirement for an external agency (or
company) such as a Certificate Authority be involved in the set up of
an LDAP server. As a result of this, the following will summarize and
contrast for each item you listed.
To issue a certificate in LDAP anyone with authorization to update
that part of the server at the issuing company can generate it. For
CA-PKI, there are recognized companies (the Certification Authority)
that will issue the certificate for the company to use. In the latter
case, the CA will also make available information to clients to verify
that the certificate they receive is valid.
At this point with LDAP, the certificate information is stored on the
LDAP server (along with the other information stored). It may also be
delivered to other systems requiring that information. In CA-PKI, you
have two parts
- the first part goes to the company / person registered with the CA
- the second part goes to the client (or perhaps better, the client application)
so the two people / companies can establish the trust relationship.
With LDAP, there is a defined method to request the information. As an
example, let's use an LDAP server to store user names / passwords for
a group of workstation. The workstation will request the username and
password, encode the password, and compare it to the value fetched
from the LDAP server. If they match, the user is authenticated.
With CA-PKI, and you go to a secure web site (as an example), part of
the setup of the connection will be an exchange of trust information.
The two parts of the information distributed / stored above are used
to help establish a secure connection and provide information that the
user can use to verify everything is OK. For example, when I connect
to my bank using a secure web browser, I can pull up a description of
the certificate indicating:
- the name of the company I am dealing with
- the name of the Certification Authority
- the range of dates the certificate is valid
as well as a variety of other information that experts could use to
verify the certificate (the application already said its OK).
What are the advantages / disadvantages?
This was answered in part above based on the different types of
application domains. In terms of security, LDAP is only as secure as
the server on which the information is stored. For many purposes, the
LDAP server is the authoritative basis of the information (as above -
the user authentication). This also works best when the access to the
network is controlled so you can prevent "man in the middle" attacks
and similar problems.
In CA-PKI systems, the security comes from
- an independent company / organization that identifies the company /
person that will receive the certificate
- independent distribution of public key information (the private
part at the company, the public part in each client application)
- strong encryption methods used to validate the identify of both systems
This works on both secure networks as insecure ones (such as the Internet).
Source Code
For LDAP, check out
http://www.openldap.org/
which has an open source implementation of an
- LDAP server
- LDAP replication server (for reliable operation)
- libraries that implement the LDAP protocol
- sample programs, utilities, and tools
For an implementation of CA-PKI, check out
http://www.apache-ssl.org/
for the server side and
http://www.mozilla.org/releases/
for the source code of Mozilla which includes client software or a
more simple example at
http://www.codeproject.com/internet/wininet_ssl___certificate.asp
which is a windows example, but much shorter or
http://www.javaworld.com/javaworld/javatips/jw-javatip96.html
which is a Java example. A site with several examples that should also
compile for Linux is at
http://munitions.iglu.cjb.net/dolphin.cgi?action=render&category=0209
Technical definitons for LDAP
Defined in RFC-2251 titled "Lightweight Directory Access Protocol (v3)
http://www.faqs.org/rfcs/rfc2251.html
RFC-1777 titled "Lightweight Directory Access Protocol"
http://www.faqs.org/rfcs/rfc1777.html
which obsoletes RFC 1487 titled "X.500 Lightweight Directory Access Protocol"
http://www.faqs.org/rfcs/rfc1487.html
There are a number of complementary standards for LDAP as well. I
suggest a review of
http://www.faqs.org/rfcs/rfc3600.html
which lists the currently (December 2003) active standards and a quick
search for the string LDAP will help you find other related standards
including those related to implementing passwords, certificates, and
so on from an LDAP server.
Technical Definitions for PKI
RFC-2560 titled "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP"
http://www.faqs.org/rfcs/rfc2560.html
RFC 2459 titled "Internet X.509 Public Key Infrastructure Certificate
and CRL Profile"
http://www.faqs.org/rfcs/rfc2459.html
There are other related methods such as
http / https
RSA encryption
and so on that may provide additional details if you need them.
To search for more information, try searches such as
https client source code linux
secure https server source code linux
RFC PKI
RFC LDAP
standard LDAP
standard PKI
compare PKI LDAP
and so on.
If you have any questions on this answer or if I've missed the target
in any way, please use a clarification request and describe what
additional information is needed.
--Maniac |
Request for Answer Clarification by
irene450-ga
on
10 Dec 2003 19:46 PST
I did a general research on it. However, your answer does help me
too. Thanks a lot.
Can you please tell me more about how each component communicates with
others in CA-based PKI and LDAP in technical term? (e.g. what protocol
it uses)
links are good, but it is not very helpful for me.
About the Technical defination, can you please tell me the important
points, outline or summary for (standard) PKI and LDAP in technial
terms.
e.g. Defined in RFC-2251 titled "Lightweight Directory Access Protocol (v3)
http://www.faqs.org/rfcs/rfc2251.html
how would u do to set up a PKI and LDAP? what's needed for a linux
box? (only for linux please) again, in technical terms please.
sorry if you have already answered any of above questions. If so,
calarity it please.
Thank you very much. again, tips (>= 10) will be given for execellent answer.
|
Clarification of Answer by
maniac-ga
on
11 Dec 2003 19:24 PST
Hello Irene450,
To give you some more "technical details" on both LDAP and PKI, I will
work through an example for both.
Taking LDAP first, let's first look at the standard referenced in the answer at
http://www.faqs.org/rfcs/rfc1777.html
From section 3.1, it indicates the connection should be via TCP on port 389.
From section 4, it indicates there are messages from the client to the
server (LDAPMessage - a variety of types) with responses from the
server to the client (LDAPResult).
From 4.1, it says the first client message must be a bind operation.
Depending on the LDAP server, an anonymous bind may be sufficient, or
you may have to provide a suitable authentication (clear text
password, or kerberos token).
From 4.3, there is a description of the search operation. For
authentication purposes, this is generally what is used. You have to
specify a "base" of the search. That is a text string such as
"ou=people,dc=berkeley,dc=edu"
which identifies the fields. You also have to specify a search filter such as
"(uid=maniac)"
Optionally, you can specify which attributes to be returned if you
want to reduce the amount of data returned. There are a number of
other items that should / could be set - see the RFC for details.
Again, in 4.3, there is a description of the response which is zero or
more responses as search responses with the data requested. This
sequence of responses is terminated by the success or error status.
As described in 4.2, you should also send an "unbind" operation to
tell the LDAP server you are done with searches.
A relatively simple example of this sequence, written in Perl can be seen at
http://ldap-project.berkeley.edu/code/code-example-perl01.html
It uses a Perl module to perform several of the steps, but the
sequence taken is described as above. In other languages or with other
libraries, it may take more or less code but the basic sequence should
be the same in each implementation.
For PKI, I will use the example of establishing a secure HTTP
connection described in
http://www.faqs.org/rfcs/rfc2660.html
You may want to review the processing model in section 1.3 or examples
in section 10 for additional information for the example. The
following focuses on the handshake necessary to establish the
connection with the remaining messages sent as HTTP over the secure
link.
The main differences between secure HTTP and normal HTTP include:
- connect using port 443 instead of 80
- the client sends security information identifying its capabilities
- the server sends its security information and a certificate
indicating its identify plus a session id
- the client is now responsible for authenticating the server. If
this fails, the connection is terminated. Otherwise, the client will
generate a "permaster secret", encrypt it with the server's public
key, and send it to the server (plus the client's certificate if the
server requested it). The client then generates the "master secret".
- if the server requested the client's certificate, it will
authenticate the client. If that fails, the connection is terminated.
If the connection is still up, the server will decode the premaster
secret with its private key and generate the same "master secret".
At this point, the authentication is done (server, and optionally
client). Both systems also have a "master secret" which was never sent
across the wire. Both the client and server will generate session keys
from the "master secret" for encoding the data and checking the
integrity of the data transferred. Both sides will exchange messages
encrypted with the new keys to complete the handshake. The secure link
has been established, and the regular HTTP messages are exchanged over
that secure link.
There is a pretty readable explanation of this process and the related
protocols and material at
http://www.harmonysecurity.com/paper_ssl.html
I can answer the new question
How do I set up a PKI and LDAP (for Linux)?
quite simply
Install the appropriate packages for your Linux distribution.
I provided references to both
Open LDAP (both server and client libraries and applications)
http://www.openldap.org/
MOD_SSL (a module providing PKI for the Apache Web Server)
http://www.apache-ssl.org/
Both sites have good instructions on how to build these products for
your Linux system.
Good luck with your work.
--Maniac
|
Request for Answer Clarification by
irene450-ga
on
12 Dec 2003 17:42 PST
I think I did not make myself clear.
um...let say in a PKI, the CA needs to communicate with the repository
(a x.500 directory) where the certificates are stored using LDAP when
a client wants to get the public key of other clients. How do we
ensure that the CA "talks" to the genuine repository? and not a phony
repository with fake public keys established by a hacker? If a hacker
can make the CA talking to him, then the PKI is useless. What makes
it preventing from being compromised?
I really want to give u 10 stars. btw, how can I tip you? sorry, i
am new in google answer.
thanks a lot
|
Clarification of Answer by
maniac-ga
on
13 Dec 2003 07:27 PST
Hello Irene450,
Q: The CA needs to communicate with the repository (a x.500 directory)
where the certificates are stored using LDAP when a client wants to
get the public key of other clients. How do we
ensure that the CA "talks" to the genuine repository? and not a phony
repository with fake public keys established by a hacker?
A: I am not quite sure what situation you are trying to describe but
let me take a shot anyway. The Certification Authority (CA) is the
organization that issues the certificate. They *know* they have a good
certificate. If they operate an LDAP server to distribute the public
keys for client companies, they need a secure method to access that
server. In some cases, that LDAP server will be at the CA's company
and they would have a set up similar to
Private Net <--> LDAP Server <--> Internet
where they have a controlled link to the LDAP server to make updates.
In the case where they have the LDAP server at a large site with good
internet access (e.g., MAE East), they would use a secure method
(e.g., secure shell) to connect with that system and make the updates.
A description of how one company does this is described at
http://www.signatur.rtr.at/en/directory/access.html
which also describes the use of dedicated servers for specific
purposes, separate networks, and firewalls.
Q: If a hacker can make the CA talking to him, then the PKI is
useless. What makes it preventing from being compromised?
A: I am also not quite sure what the hacker would do with a set of
public keys. They are "public", any user can and should have access to
them. The private keys must be kept secure and they are distributed to
the CA's clients by another method.
It would be more serious if the hacker could take control of the LDAP
server (or spoof it to other clients) and publish their "public" keys
as the keys of responsible companies, but that's a different problem.
To a certain extent, that particular problem is mitigated by broad
distribution of the public keys in independent methods. The "bad" keys
won't match the others and can be weeded out.
To answer your rating and tip question, please see
http://www.christopherwu.net/google_answers/answer_guide.html#answered
which has a good illustration of the process.
--Maniac
|
Request for Answer Clarification by
irene450-ga
on
13 Dec 2003 08:00 PST
hi,
I am sorry that I don't quite understand the answer to the 2nd
question. Let say a hacker makes a fake public key and put it in a
fake x.500 directory. When a client wants to get the public key of
merchant A, he gets the fake public key. Therefore, he "talks" to the
hacker instead of merchant A. Is it possible for hacker to make such
a connection to the CA and do something like I mention above? If so,
how do we prevent it from happening?
Sorry to keep bothering you. This is the last question I have.
Thanks a lot.
|
Clarification of Answer by
maniac-ga
on
13 Dec 2003 09:38 PST
Hello Irene450,
>Let say a hacker makes a fake public key and put it in a fake x.500 directory.
OK.
>When a client wants to get the public key of merchant A, he gets the fake
>public key. Therefore, he "talks" to the hacker instead of merchant A.
Why? If the client (of merchant A) makes a connection to merchant A's
site, they should get merchant A's public key, not the fake public
key. That is because merchant A's site has their key, not the fake
one. [assuming the hacker has not compromised the merchant's site]
If the merchant's client gets directed to the hacker's site and gets
the fake key, that is a different problem. For example, one way to do
this is to poison the DNS lookup used by the client to return the
hacker's IP address and not the merchant's IP address. When the client
does the lookup with the fake address, they get the fake key. That
gets into the security / reliability of the DNS lookup and not of the
LDAP server itself.
Q: Is it possible for hacker to make such a connection to the CA and
do something like I mention above? If so, how do we prevent it from
happening?
A: I don't see where the Certification Authority (CA) comes into your
example. As I described above, the situation you described only
involves the merchant (who is a client of the CA) and the client of
the merchant.
As an alternative, the CA could do something like:
o have their own LDAP server w/ copies of public keys of their
clients (merchants) so you could get the keys there and/or compare the
copies you get from merchants with this "master copy"
o issue certificates which include the merchant keys, but this is
already part of PKI.
o work with client software providers (e.g., a browser) and provide a
set of public keys with the client software
and other methods.
--Maniac
|
Request for Answer Clarification by
irene450-ga
on
13 Dec 2003 11:10 PST
It seems like I mistyped a few words (maybe more than a few) in the rating ^_^".
Can you please tell me the solution that preveting DNS from being
poisoned? I know it's out of the scope of the original question.
Hope you have time to answer it for free. Thanks a lot.
|
Clarification of Answer by
maniac-ga
on
13 Dec 2003 17:44 PST
Hello Irene450,
Thanks for the kind words.
To answer briefly the DNS poisoning query, let me suggest a search in Google with
DNS poisoning
as the phrase. This brings up a number of very good pages with
information. The first one in particular includes proof of concept
code to demonstrate (but not implement) the algorithm described in the
article.
Good luck with your school work.
--Maniac
|
,
0 Comments
)