> 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'm an interloper. The associated enhancement request page has to do with 
support for external identities in FreeIPA, which later was determined to 
merely be a use case for something they were calling "Views". This page just 
shows three methods that an external user might use to arrive in the local 
domain. I consider it "supporting information". In any case, I'm definitely a 
user, not a developer.

> You intend to crossover between authentication protocols,

Mechanism 3 is a little pie in the sky, but the sky is not as far off as it was 
five years ago. :)

> 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.

That's mechanism 2, sort of. I think the intended use of PKINIT is for end 
users to AS into the remote KDC. Mechanism #2 could definitely be broken into 
2a  (User->Outward KDC) and 2b (Inward KDC -> Outward KDC).

You may be interested in the more recent PKCROSS by Nico Williams 
(http://tools.ietf.org/pdf/draft-williams-kitten-krb5-pkcross-02.pdf). Your 
DANE proposal could potentially strengthen the current draft's "Leap of 
Faith/Trust on first use" notion, which I was already happy with. I'd also be 
happy using the CA bundle typically included with browsers. If It's good enough 
to get people to type passwords into the browser, its good enough to identify 
whomever issued the identity. Petty technicalities like not having the right 
flags set are a nonissue for me.

>  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.

Neat.

> > 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?

I'm saying that automatic keying doesn't exist yet, and thus on-the-fly xrealm 
connections will fail. :) Whether it's for individual cross-realm principals or 
for krbtgt/C@S, the MIT krb5 KDC may need a plugin which supports automatic 
keying of cross realm principals.  A database plugin might do it, but I've not 
prodded this in enough detail to say. It may require changing code somewhere 
else in the AS...

Bryce





This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to