Exclusive!! real life need Lava Kafle Ms by Research in Computer Science Kathmandu University cell: 9841224387 9801034557
On Thu, Dec 19, 2013 at 3:11 AM, Sean Baker <[email protected]> wrote: > 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: [email protected] > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
