|
Posted by lynn on August 17, 2005, 3:25 pm
Please log in for more thread options
Serge Ayotte wrote:
> Hello to all... If the following is part of a white paper or other
> 'net resource, please direct me to it... After many trial on Google, I
> can't seem to hit the right word combination :)
> Never having touch (for not needing it) certificate/pki, I am a bit
> lost now...
>
> I need to secure a SharePoint Portal Server site that will be access
> from the "outside" of the network (this SPS is running on a member
> server of a SBS2K3 domain). I already have SSL and permit only that,
> but I was asked to look into a "stronger" method of making sure that
> the people accessing it are allowed.
> Aside from user/password I immediately thought that a client
> certificate would be the way to go, but now I am a bit lost in all the
> information I got from MS and Technet about client certificate.
>
> To give a certificate to someone to import on his computer, do I HAVE
> to have him connect to a Certificate server site for that? Isn't there
> a way for me to be able to generate the certificate and send it to the
> "outside partner" I want to give access to the site?
>
> If I am correct, I could then associate the certificate to a login
> account, so in a way having a double security level (i.e.
> username/password not enough to access, or only the certificate not
> enough also).
>
> Thank you in advance for any and all hints, tips, trick and direction
> you will provide... Very much appreciated in advance!
from an administrative standpoint ... get a server that supports RADIUS
authentication .... it is probably the most pervasive authentication
methodology on the internet today ... being extensively deployed by ISP
and large number of other organizations. For instance, if you have ever
setup a computer for PPP/dial-in access to an ISP ... typically there
has been a screen where you select one of 3-4 different authentication
mechanisms ... this is typically then what your ISP or corporate
datacenter has prespecified for your particular account in a RADIUS
infrastructure.
In addition to authentication, RADIUS also provides additional optional
capability for supporting authorization, permissions, and accounting on
an account by account basis.
RADIUS supports a number of different authentication paradigms ...
having originally started with userid/password ... but there are
versions that have been extended with other types of authentication
methodologies ... where you can actually select the authentication
mechanism on a account by account basis (or userid by userid).
One authentication mechanism is recording public keys in lieu of
passwords and doing digital signature verification
http://www.garlic.com/~lynn/subpubkey.html#radius
this is using the registration of public keys, on file in the radius
infrastructure for performing digital signature verification w/o
requiring PKIs, certification authorities, and/or digital certificates.
http://www.garlic.com/~lynn/subpubkey.html#certless
the basic technology is asymmmetric key cryptography ... where what one
key (of a key-pair) encodes, the other key (of the key-pair) decodes.
This is in contrast to symmetric key cryptography where the same key is
used for both encryption and decryption.
a business process is defined called public key, where one of the
asymmetric key pair is identified/labeled "public" and freely
disclosed. The other of the key pair is identified/labeled "private" is
kept confidential and never disclosed.
a business process is defined called digital signature. a hash of a
message or document is calculated and encoded using the private key,
yielding the digital signature. the message is combined with the
digital signature and transmitted. the recipient recalculates the hash
on the message, decodes the digital signature with the corresponding
public key and compares the two hashes. if the two hashes are equal,
then the recipient can assume that
1) the message hasn't be modified in transit
2) "something you have" authentication, aka the sender has access to
and use of the corresponding private key.
this is slightly modified for pure authentication ... using a
challenge/response protocol. The server sends the client some random
data as a challenge (as countermeasure to replay attacks). The client
calculates the digital signature for the challenge and returns just the
digital signature (since the server has the challenge). The server
calculates the challenge hash, decodes the client's digital signature
that was returned and compares the two hashes.
there are various kinds attacks that a server and/or imposter may mount
on a client. as countermeasure for some of these attacks ... the client
actually adds some of their own random data to the challenge before
calculating the digital signature. the client then returns both their
added data and their digital signature to the server. the server now
has to calculate the hash against a combination of the original
challenge and the added data provided by the client.
At its basic there is no actual need to generate a client digital
certificate and/or require a PKI and/or certification authority. The
basic requirement for a certification authority is to certify the
validaty of some information (represented by the contents of a digital
certificate) for the benefit of other parties which have no means of
otherwise obtaining information about the party they are dealing with.
This is the first time message/communication received from a total
stranger scenario.
Fundamentally all that is needed is for the client to
1) generate a public/private key pair
2) be able to register public key with some server infrastructure
3) be able to generate digital signature with their private key
and for a little drift, one of the possible digital signature attacks
involves dual-use vulnerability involving digital signatures. there are
many instances where digital signatures are used for pure
authentication ... where the digital signature is applied to purely
random data ... that is never actually examined by the signing human.
however, there are also infrastructures where real messages and/or
documents are digitally signed, carrying with it a connotation similar
to that of a human signature, aka that the person has read, understood,
agrees, approves, and/or authorizes what has been digitally signed. so
one possible vulnerability is for an attacker to transmit to a client a
valid contract or financial transaction, under the ruse of random
challenge data. The client then automatically digitally signs the
"random challenge data" w/o ever examining what is being digitally
signed.
misc. past dual-use digital signature vulnerability postings:
http://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI
International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against
Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature
vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re:
dual-use digital signature vulnerability)
http://www.garlic.com/~lynn/aadsm18.htm#32 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication
problems
http://www.garlic.com/~lynn/aadsm19.htm#2 Do You Need a Digital ID?
http://www.garlic.com/~lynn/aadsm19.htm#24 Citibank discloses private
information to improve security
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at
MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at
MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at
MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and
authentication
http://www.garlic.com/~lynn/aadsm20.htm#28 solving the wrong problem
http://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair
protection on Windows
http://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for
smartcards
http://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing
and authorization in applets
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others
(without their private keys)
http://www.garlic.com/~lynn/2005m.html#11 Question about authentication
protocols
http://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
| 
XML Sitemap