re cross-certification questions (a short rant)

[Jeff.Hodges@stanford.edu]

> Could you point me at any examples or papers describing the use of
> Kerberos  SASL mechanisms on the wide-area Internet, especially where
> the client and  server are located in different organizations?  

I presume that here you meant to say "Kerberos mechanisms" -- because it is 
essentially irrelevant whether they were initiated via SASL or not.

No, I don't have any references at my fingertips, but have queried 
krb-protocol@MIT.EDU to see if they know.

Yes, there is cross-certification facilities in kerberos, and it nominally 
works. However, it features n**2 scaling issues.

Kerberos scales quite well as a primary key distribution protocol within an 
administrative domain. Such domains may contain non-trivial numbers of people. 
Stanford, UMich, and MIT are prime examples. Nearly 40K people (and growing) 
in our case. UMich is significantly larger. I'm not sure about MIT.

> There is specification work going in PKIX and elsewhere on how to handle
> cross-certification for use by Start TLS, but I am not familar with
> that kind of activity for Kerberos. 

By "Start TLS", I'm assuming you meant to say simply "TLS". 

Yes, cross-certification seems to be a large-in-scope subtle-but-important 
issue.

Nominally, public-key-based (i.e. asymmetric) ciphersuites will scale better 
across administrative domains than secret-key (symmetric) ones -- because you 
just hand your public key out to everyone and forget about it. BUT, the rub 
comes when people who've ended up with your key want some assurance that it is 
indeed your key -- they want to know how much to trust it, and need some way 
to figure this out. This is, I think, what the PK-based security mechanism 
folks are talking about (at a high level) when they say "cross-certification"

I tend to believe that at a high level, the PK-based folks' real-world 
cross-certification scaling issues are of roughly the same order of magnitude 
as the secret-key-based folks'.

That said, I think that authentication across administrative domain boundaries 
on the Internet at large is presently a research topic, and we should not let 
trying to accommodate it hold up our present work. I.e. we should not forgo 
profiling Kerberos with LDAP just because it has cross-certification (i.e. 
cross-admin-domain) scaling issues.

Note that mechanisms such as Kerberos (and CRAM-MD5) being "intra-" 
administrative domain solutions ~does not~ necessarily mean they are 
topologically limited. This is an important point for overall security of 
intranets (and thus by implication, the Internet). For example, when I grab my 
laptop and travel to IETF meetings and then connect back to Stanford (e.g. my 
desktop machine in my office, plus our AFS-based distributed file system) from 
the IETF terminal room, I'm authenticated via Kerberos and my sessions are 
encrypted - no passwords in the clear. We essentially provide ourselves a 
Virtal Private Network capability with this technology, and have been doing it 
for quite a while.

Thus, we ~can~ address, with mechanisms such as Kerberos (and even CRAM-MD5), 
the immediate non-trivial security issues ~within~ administrative domains and 
without topological restrictions.

I think that that is very worthwhile. I also think that we, as application 
protocol designers & implementors & deployers, can worry about explicitly 
facilitating cross-administrative domain security when the real-world issues 
are better understood and addressed by the security mechanism designers and 
implementors.

Jeff