I've run across a bit of a problem locally which I'm wondering if there
is interest in a general solution for, or whether this is going to just
need to remain a local mod. Let me try to explain what's going on
through a scenario, as I promise if I use real names it's likely to be
even more confusing.
Alice and Bob are two members of an organization, and each runs their
own root Certificate Authority within the company. Both CAs issue
certificates for user and machine identification (including S/MIME).
Alice issues her certificates in a three-tier'd system (root,
intermediate, leaf), while Bob has implemented a half dozen tiers within
his structure (root, intermediate-1, intermediate-2, ... , leaf).
Alice has implemented CAS for authenticating her users [Bob's users
don't need access to the systems, nor are they likely to] and employs
CAS' exceptional ability to do CRL checking without having to restart
every time those are updated [currently hourly - she runs a tight ship!].
One day - completely out of the blue if you ask her - Alice is reminded
that she actually works for Bob, and that that means her certificates
should integrate in a trust chain. To keep things working until Alice's
root CA expires, management decides that a cross-signed trust must be
established between the two trees, such that Bob Intermediate Cert-2 is
going to sign Alice's root certificate, and both will continue to exist
in the wild. Neither is given an option in this arrangement.
Over time as emails bounce back and forth, both Alice and Bob's systems
begin to discover what has happened through the magic of chain
completion, but due to implementation bugs [which are beyond the scope
of this conversation - Very Large Customers cannot seem to get them
fixed], machines in Alice's domain begin to become confused about what
'right' looks like. This manifests itself in CAS AuthN when they begin
to present a certificate chain to the server which instead of chaining
back to Alice's Root CA chains back to Bob's Root CA through the
bridge. Fred would be an example of this. Fred presents Fred->Alice
Intermediate->Alice Root CA->Bob Intermediate 2->Bob Intermediate 1->Bob
Root CA, but CAS errors out when it begins to evaluate a certificate
which isn't actually in the Tomcat truststore and for which it doesn't
have a CRL, denying Fred access he should legitimately have.
To my [perhaps incredibly naive] read of the code, Alice now faces three
options:
1. Only examine the leaf certificate presented by the client.
1. Most implementations of this are going to be a bit brittle, but
that should be considered in context of:
2. There is no requirement in the protocol [at least none
respected] that a client actually present their certificate
chain when attempting to authenticate; they may choose to send
only the leaf certificate if that suits them.
3. Evaluating only the leaf certificate means that intermediate
certs are not examined for revocation. Obviously a rare event,
but principally that's bad; especially if you're already
updating CRLs hourly.
2. Build the chain from the TC truststore [or a configured one] and the
presented leaf certificate, arriving at a chain which can actually
pass validation.
1. In Alice and Bob's case, the example would be Fred above whose
certificate submission would be refactored to terminate at Alice
Root CA (as the self-signed version) instead of the submitted chain.
2. This is a good bit of work per AuthN (relatively speaking
anyway), but is the most secure [up to date CRL checks for all
certs in the final chain; all signatures verified].
3. Force users to be properly configured to handle the completely
confused hierarchy.
1. Throw-away - BYOD has made this functionally impossible for the
chain discovery & bug issues.
In the real world version of this I've implemented a POC of #1 through
an 'ignoreClientChain' property which can be set in
X509AuthenticationHandler, achieving a marginally acceptable result, but
I'm wondering whether there is any community interest in the capability,
and if so which COA is perceived as best for everyone?
Thanks!
Sean
--
Ne Desit Virtus,
Sean R. Baker
1LT, MS
United States Army
Office #: (301) 319-0712
Email: sean.ba...@usuhs.edu
--
You are currently subscribed to cas-dev@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
