Pros and cons of alternatives to our existing MIT Kerberos
authentication infrastructure
Note: we are really only concerned with the server-side (KDC) here.
Whatever we do, DICE client-side is probably most sensibly handled through
the distribution's supplied packages, as they are integrated with the rest
of the distribution. We rely on the existing
code for other platforms, and they seem to work well enough. However,
there may be implications for some of the admin tools and PAM modules,
as noted below.
Recommendations:
- Given the state of flux with the EASE KDCs, this would not be a good
time to move all our authentication to use them.
- We should migrate from an MIT KDC as supplied with SL6 (current situation)
to an MIT KDC built from source.
- We may want to consider the principle of moving to EASE now, though
deferring any implementation until a later date.
- If we do not reject EASE on principle now,
we should revisit this possibility
in a couple of years once their upgrades are done and the "devolved principal
mangement" is in place and we can evaluate it properly.
- We should continue to track Heimdal, and re-evaluate its use as
appropriate.
MIT KDC as supplied with SL6 (current situation)
Pro:
- Seems to run well enough
- Doesn't require much maintenance in general (but...)
- Comes pre-packaged with SL6
- Client-side integrated into SL6
- We have full access to the logs
- for debugging
- for security and incident response
Con:
- Version upgrades can come along with little warning, and force us
to do work to test and enhance configurations
- e.g. 1.9 went to 1.10 in a "routine" SL6 package update
- OTOH versions can be a bit behind what we would like
- We could really do with 1.11 for incremental propagation
- RH appear to be generally less interested in server-side code (cf. OpenLDAP)
- Platform upgrades usually also involve a Kerberos version change, which
complicates testing
- ... and we have to hope that they don't impose something a bit
bigger (such as a move to Heimdal) on us
MIT KDC built from source
(Only for KDCs; client side would continue to use RH packages.)
Pro:
- Reasonably close to what we currently have, so low conversion effort
- Package and version stability, with no nasty surprises
- Gives us much better control over changes, upgrades and features
- Decouples KDC upgrade cycle from server/OS upgrade cycle
- Existing admin tools and PAM modules should continue to operate
- Minimal user visibility for change
- We have full access to the logs
- for debugging
- for security and incident response
Con:
- A bit more work to track versions and build as required
- Specifically, we would have to watch out for security releases
- Packaging might need some care so as to allow both to exist on servers
- Possibly some component tweaking to allow server-side and client-side
configurations to be generated for different packaging
- Perhaps split component into two: one for client and one for KDC?
krb5.conf
use may complicate this
- If we're changing the server anyway should we be more radical?
Heimdal KDC
(Only for KDCs; client side would continue to use RH's MIT packages.)
Pro:
- Being integrated into more products (MacOS, KfW)
- ... so should probably ramp up our Heimdal expertise anyway
- Some big sites have gone over to Heimdal
- Now pretty robust
- More agile development than MIT?
- Additional things built in
- kx509?
- NTLM
- How many of them would we use in practice?
- Little user visibility for change
- We have full access to the logs
- for debugging
- for security and incident response
Con:
- Conversion effort could be considerable
- Database conversion, though tools do exist
- New component for management differences
- Some changes to PAM modules probably required
- Knock-on changes (e.g. to prometheus, kdcregister)
- Some learning
- Documentation seems more fragmented
- A bit of work to track versions and build as required
- Specifically, we would have to watch out for security releases
EASE
Note: the "EASE" that people seem to want is the cosign
authentication. It's not clear that they particularly care about the
underlying Kerberos technology. Indeed, IS's own
what is EASE
page describes it as a "web login service", and though there is some
mention of Kerberos it doesn't get much prominence.
That being the case, it is possible to
set up cosign
to speak to the EASE servers, which would then authenticate against the
EASE KDCs.
The "EASE" we're considering here, then, is completely replacing our
own KDCs and cosign servers with the EASE ones.
The EASE admindocs
have links to a number of EASE-related topics.
Pro:
- One (or more likely half) less thing for us to look after
- Accounts created for us by the centre
- Arguably gives more integration with the rest of the University
- though AD still separate, apparently for licensing reasons
- we do currently have a cross-realm link with the EASE realm
- ... and transitively to AD
Con:
- Use-cases not yet clear or costed
- Considerable user visibility for change
- Not integrated with our machine installation process
- Current EASE methods for setting up host and service principals
are very cumbersome
- manual round-trip via UniDesk!
- wouldn't scale at all well
- not clear how (or whether) they could be automated
- "devolved principal management" is on their list
- has actually been for some time, but no identified effort
- Kenny now looking at it as part of EASE KDC upgrade
- timescales and actual facilities and interfaces offered aren't clear yet
- how does wallet fit in?
- Tim and Simon's document
- Most of their "Why Informatics Cannot Use The EUCS KDC" section still apply
- If we have to run a KDC for host and service principals anyway, the
management gains would be small, and more than outweighed by other
complications
- No control over accounts created (or not) for us by the centre, or
visibility as to why
- No control over who has user principals, so some implicit authz lost
- Restricts our incident response options
- Logging would be pretty much unavailable
- Debugging becomes much harder
- Security and incident response would be much slower, as we would have
to interact (via UniDesk) with IS for information and to effect changes
- Not integrated with prometheus: would still have to do authorization,
home directory management etc. ourselves
- Outside dependencies
- No EdLAN would mean that much of Informatics would stop
- no logins
- some AFS access would break
- many routine tasks are Kerberos-authenticated
- most sysadmin tasks are Kerberos-authenticated
- in particular, many faults would become very difficult to diagnose,
as access to relevant data would be blocked
- Might be possible to get a local KDC if physical security issues
can be sorted out
- still not as robust as we currently have
- managed by IS, so worst of both worlds: no management access for us,
harder physical access for them
- unlikely to be one per Informatics site, as we currently have for
robustness
- Risk of accidental breakage of our systems by non-Informatics people
- User support chain much longer and more tenuous
- Could we still make documents visible only internally?
- do we much at the moment?
- Gives us no control at all over versions, features, policies
- ... or indeed major version or platform changes
- EASE currently running a seriously old version of the MIT code
- We require certain settings for AFS for example
- What would we do if they decided to move everything to AD??
- Some doubt as to how EASE password security compares with
our own current practice
- Who can reset them?
- What constraints are there?
- Are initial passswords retained and still visible?
- UniDesk
- Would have to ensure that our PAM modules and remaining admin tools
interoperate properly with whatever IS go with at the time
- ... to their schedule whenever they decide to change things
- How does iFriend fit in? (Probably not at all, so we would have
to migrate existing Friends.)
Active Directory
Everything that applies to the "EASE" section above would apply to AD
(ED.AC.UK realm) even more so!
Composite approaches
- Use EASE for user authentication, and our own KDCs for
host and service principals.
- Not something that many (any?) other sites do
- Implementation nightmare
- Management nightmare
- Most "EASE cons" above still apply
- Use cross-realm relationship with EASE to allow our cosign and web
servers to accept EASE.ED.AC.UK factors and/or the EASE cosign servers
to accept INF.ED.AC.UK factors.
- Should be possible in principle, but...
- User interface issues
- might not matter if pages didn't care which of INF or EASE factors
they accepted
- Probable implementation issues
- Likely support and debugging headache
- Would probably just work in some cases where a user
already had an EASE tgt
- ... but probably not a big enough use-case to be worth putting
effort into it
- See also Simon's email
$Id: ProsAndCons.html,v 1.65 2013/05/02 15:26:05 gdmr Exp $