Bruce -
To understand of how SSL provides authentication requires some knowledge of
how digital certificates work and their role in the PKI(Public Key
Infrastructure). Here is some quick vocabulary that we will need to get
through this. Note that those definitions are applicable in the context of
MQ Security.
Authentication - a process of verifying claimed identity.
Identity - set of attributes, public and private.
Access Control in this context can be substituted by authorization. Granting
or denying a permission to perform some task.
Link level security - MCA/MCA. Under Link level security following items are
true. MCA can authenticate their respecting counterparts, meaning if that
MCA A says that it is MCA A, MCA B has a way to verify that. How and why
this is crucial I will explain later. Channel exits also provide not much
more than Link level security.
End-to-end security is implemented at the application layer and such securty
services as confidentiality, authentication and integrity are performed at
that level. This is a lot more fine grained than link level security.
Public key a key that is available for public freely.
Private key a key that is held in secret by its owner.
OK. Hold on to your hat. This is how SSL provides authentication besides
many other services such as confidentiality, integrity and non repudiation.
The descriptions here are symbolic an not to show detailed functionality but
to demonstrate a concept.
1. Bob wants to talk to Alice securely.
Bob takes Alices Public key and encrypts it. Only Alice can see the message
because only Alice has the Private Key.
2.Alice wants to know that message came from Bob and not someone else.
Bob encrypts his message with his private key. Note that this does not
reveal his private key to anyone. Same public and private keys can be used
for encryption and decryption as longs as private are held in secret and
public ones are avaliable. So, Alice gets the message and decrypts with
Bob's public key. In this scenario, everyone can see the message and
everyone know that it could ve came only from Bob. This is more without lot
's of other details is called digital signing.
Now, the problem in the real world that there are so many Alices and Bobs
that we cannot keep track of associations between them and their keys. So,
there are certification authorities. Just like government issues the
passport that says your name is such and such, your height, etc. This
information had been verified by the passport issuer. Certification
authorities take your name i.e. MCA A, MCA's public key and sign all that
with their key. Know when you are presented with a certificate, you can
state a lot more that just the fact the certificat is valid. You know who
you are dealing with because you have trust in the CA that issued the
certificate. Except the name in the certificate is a lot more structured.
Contains atribute value (AV) pairs such as DN, C, OU, O and many others. You
can use that information to perform DN matching that will result in weather
you will allow a connection to exist or no.
Here is something very important. Under link level security, ones security
controls are very limited. Using a channel exit logic, or MQ SSL
functionlity such as DN matching all you can do is to say weather the
connection will take place or not. That's IT. This is as much as you can do.
Neither using SSL, nor channel exits you can enforce authorization rules
onto mq objects other than the connection itself. Once the connection had
been allowed. OAM, RACF, PDMQ or whatever else will take care from there
using either default settings or some channel attributes.
Your queue manager has SSL key repository. That stores following important
infromation.
1.Certificate of your queue manager, so your clients can decide wether to do
business with you or not. Just like you get one from the web server when you
establish SSL connection, your clients will get one.
2. Public certificates of all the Certificate authorities that you trust or
individual certs that you trust.
Here is how item#2 in your key repository can make life a lot easier.
DN matching can prove to be very unscalable and hard to manage as the number
of your clients grow. And I am sure at some point it might even become
impossible. Because you have PKI at your hand, security administration can
become a lot easier. Here is how: Your organization could create its own CA
issue certificates to all your MQ clients. You in on the other hand could
cofigure your Queue manager to trust only MCA's that have certificates that
were signed by your company's CA. If you deal with many business partners
you could outsource Key Management to some other organization such as
Verisign. And then keep the cerificates of your business partners in your
key repository, so you can trust them. Bottom line, using SSL you make your
decisions cost effectively and extensibly wether the connection will take
place or not which is one of the goals of link level security. Dont forget
that with SSL you also get message confidentiality and integirty.
HTH.
Mikhail.
Middleware Security Consultant.
-----Original Message-----
From: Bruce Giordano
To: [EMAIL PROTECTED]
Sent: 7/15/2002 9:01 AM
Subject: Re: MQSeries Client Security - SSL
Unless I'm missing something, I don't see that the SSL support is
providing
true authentication at least as I use the term. It lets you know that
the
client or queue manager coming across has a valid certificate. What it
doesn't do is let you know who this client or queue manager is. That
means
you also can't use it to provide access control. Access control still
seems dependent on the passed userid. This still requires use of a
security exit on both sides since you can't really trust the passed
userid
otherwise.
Since I'm still digging thru the 5.3 documentation, I may be incorrect
on
this. This is my take on what I've seen so far though. Any other
comments?
- Bruce Giordano
Prudential Insurance
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
