Subject: Cross-realm authentication

From: Christopher Walstad <[email-masked]>
Date: Tue, 07 Sep 2004 17:17:58 -0400

Dear colleagues,

We have recently started a project to analyze the cross-realm 
infrastructure of Kerberos 5.  Here are a few questions for developers 
and administrators.  Answers or comments would help us get a sense of 
the present and future of cross-realm authentication, and help us direct 
our resources.

1. How widely used is cross-realm authentication in practice?  Is there 
any difference in how various types of organizations (academia, 
industry, government, ...) use it?  How does its use scale in practice 
with the size of the organization?  Is there any difference in setups 
that are primarily Unix and primarily Windows?  How is the issue of 
trust dealt with in practice?  How much administrative overhead is 
required to setup an inter-realm infrastructure?

2. It appears that there is not current work on PKCROSS.  Do you 
anticipate resuming work on this document in the future and, if so, are 
there outstanding questions related to it?

3. How prevalent is the hierarchical organization of realms, and are any 
other types of organization commonly used?

4. We noticed that there is little recent work on SESAME, the European 
cousin of Kerberos.  Is this project still active?  If not, why? Is 
SESAME in use?  Have any of the original ideas of SESAME been 
incorporated into Kerberos (or being considered)?

Thank you for your replies.

Regards,

Iliano Cervesato
Aaron Jaggard
Andre Scedrov
Chris Walstad

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Sep 2004 16:29:51 -0500

> required to setup an inter-realm infrastructure?

There is no seamless, public Internet Kerberos V cross-realm trust
hierarchy, though there could be such a thing and though there are
chunks of the Internet (mostly .edu's) which do have cross-realm trusts.

That said, you're likely to find cross-realm trusts in large corporate
intranets.

> there outstanding questions related to it?

Kerberos V extensions must come to pass first, then we can do more than
talk about PKCROSS.

I've seen one product though that claims to support PKCROSS as
per-CableLabs specs.  Do not expect any future IETF standards track
PKCROSS to be interoperable with any existing non-IETF PKCROSS specs.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Sep 2004 18:01:41 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Sep 07, 2004 at 05:17:58PM -0400, Christopher
    Nicolas> Walstad wrote:
    >> infrastructure of Kerberos 5.  Here are a few questions for
    >> developers and administrators.  Answers or comments would help
    >> us get a sense of the present and future of cross-realm
    >> authentication, and help us direct our resources.
    >> 
    >> 1. How widely used is cross-realm authentication in practice?
    >> Is there any difference in how various types of organizations
    >> (academia, industry, government, ...) use it?  How does its use
    >> scale in practice with the size of the organization?  Is there
    >> any difference in setups that are primarily Unix and primarily
    >> Windows?  How is the issue of trust dealt with in practice?
    >> How much administrative overhead is required to setup an
    >> inter-realm infrastructure?

    Nicolas> There is no seamless, public Internet Kerberos V
    Nicolas> cross-realm trust hierarchy, though there could be such a
    Nicolas> thing and though there are chunks of the Internet (mostly
    Nicolas> .edu's) which do have cross-realm trusts.

Can we please use the term cross-realm authentication not trust?
There are wide varieties of how much trust is implied by a cross-realm
key existing.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Sep 2004 18:07:46 -0400

>>>>> "Christopher" == Christopher Walstad <[email-masked]> writes:

    Christopher> 2. It appears that there is not current work on
    Christopher> PKCROSS.  Do you anticipate resuming work on this
    Christopher> document in the future and, if so, are there
    Christopher> outstanding questions related to it?

pkcross cannot be implemented with RFC 1510 or with
kerberos-clarifications.  It requires ticket extensions.

I think that once pkinit is done, you will see renewed interest in the
problem.  I know some of us would like to examine the assumptions
behind pkcross as it currently is specified and see if we can pull out
the cross-realm ticket extensions from the PK part.

If you wanted to work on a proof-of-concept PK procedure for sharing
keys today, I believe it could be done and would be valuable.  I
invision a service with administrative access to Kerberos KDCs that
accepts CMS or Open PGP messages and allows realms to easily set up
new keys.  I recommend ignoring the binding of these keys to specific
real-world identifiers; I'd deal with that problem as foreign
principals are added to ACLs.

---

From: Derek Atkins <[email-masked]>
Date: Wed, 08 Sep 2004 08:44:02 -0400

> kerberos-clarifications.  It requires ticket extensions.

This very much depends on how "PKCross" is implemented.  I can certainly
envision a KDC-to-KDC protocol that dynamically creates a cross-realm
shared key when an initial request is made, and then returns a normal
cross-realm ticket to the client.

This does not require ticket extensions, it just requires a "PK
Cross-Key Generator/Agreement Protocol" get tacked onto the KDCs.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Sep 2004 10:50:58 -0400

>>>>> "Derek" == Derek Atkins <[email-masked]> writes:

    >> kerberos-clarifications.  It requires ticket extensions.

    Derek> This very much depends on how "PKCross" is implemented.  I
    Derek> can certainly envision a KDC-to-KDC protocol that

I think you mean specified not implemented.  Generally, it seems
reasonable to assume that people in the IETF intend the specification
in a particular document when they use the name of that document.
Since there has been a document circulating around called pkcross, it
seems reasonable to assume that is what was meant.