Kerb/PKI Infrastructure - Who's on first?

[Sam Hartman]

>>>>> "STEWARD," == STEWARD, Curtis (Jamestown) <Curtis.Steward at trw.com> writes:


    STEWARD,>            This same sign-on would provide RSA
    STEWARD,> authentication to SSH, SSL/TLS, S/MIME, PKIX and IPSEC.

I don't understand why you'd want to use RSA auth for ssh once you
have Kerberos; draft-ietf-secsh-gss-keyex provides a nice way to
handle Kerberos auth for ssh directly.

I'm not convinced that you really want to use the same long-term
infrastructure you use for S/MIME for shorter term applications like
logging into a machine or setting up ipsec associations.

Clearly the PKI people think you do, but I remain unconvinced.

I think the best I can say about IETF protocols is that with the
exception of email protocols, all the IETF security protocols provide
you as an organization the flexibility to choose your own
authentication infrastructure and to use that infrastructure with the
IETF protocol.  As an example, both ssh and TLS support native
Kerberos authentication.

Similarly you could use  some form of PKI for your authentication with TLS and ssh.

That's all nice and mod a few bugs true at the protocol level.  It
turns out though at an implementation level that the primary
implementations of some protocols prefer a particular authentication
infrastructure and that no matter what you do, you're going to run
into problems.

For example if you choose PKI, you'll find that ssh doesn't use the
same kind of PKI that the rest uses.  If you choose Kerberos, you'll
find that Windows ssh client selection is limited and that web
authentication is frustrating.


No, the rest of us don't have good answers either.