Hello Bryce, I’m not sure what status postings on the FreeIPA wiki have — is this like an official project, or is it a place where you develop your thoughts and maybe someday propose an enhancement?
> I've spent a bit of time pecking away at this over the last six months or so. > Current thoughts are here: > http://www.freeipa.org/page/Collaboration_with_Kerberos please feel free to > edit/criticize/improve. This is cool. It’s not what I meant, but it’s definately interesting. You intend to crossover between authentication protocols, while I was thinking about kerberos2kerberos, however with on-the-fly connections between KDCs. That’s a dimension that you’re not yet covering though. I’ve started documenting this on http://realm-xover.arpa2.net/kerberos.html — we’ll have a report on the statically configured cross-realm collaboration soon, by the way. PKCROSS is an older Internet Draft, http://tools.ietf.org/html/draft-ietf-cat-kerberos-pk-cross-08 > I really haven't looked at DANE. DANE in summary: Register your certificate in a TLSA record, using a DNS name that includes the protocol (UDP, TCP, …) and the port number, relative the the hostname (kdc.example.com). Pass it through DNSSEC and anyone can validate the certificate data. The interpretation of the TLSA record is that it acknowledges a certificate in use on that protocol/port. You could use it to enhance a PKI, or to enhance self-signed certificates. The trust you are leaning on is trust in the DNS signing infrastructure. You can say all you want about self-signing, but if it helps people to engage into better security actions where they normally didn’t then I’m in favour of the practice :) > Second thing is that preliminary testing indicates that MIT krb5 wants to > have a principal defined locally for PKINIT to work. That is normal, I’d say. You need to be someone before you can start making claims and collecting service tickets. Or are you saying something else? > At the very least, you need to have something create individual cross-realm > principals in the KDC before you attempt to PKINIT. Ah, yes that sounds about right. I’m not sure a given KDC, which was designed for Kerberos in isolation, is such a good bet to welcome authentications in, say, OpenID Connect. > Can maybe do this with plugins for krb5? Haven't got that far. The GSS-API is more general than Kerberos, it sees Kerberos as “just a mechanism”, and it will switch between alternatives; it also has abilities for mechanisms wrapping around other mechanisms, http://web.mit.edu/kerberos/krb5-devel/doc/plugindev/gssapi.html Thanks, -Rick ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
