Kerberos and OpenSSH - Was:Kerberos password auth/expiry kbdint patch

Booker Bense bbense at SLAC.Stanford.EDU
Fri May 16 01:05:36 EST 2003

On Thu, 15 May 2003, Damien Miller wrote:

> Douglas E. Engert wrote:
> > Simon's excellent GSSPAI code is following along closely
> > with the IETF "GSSAPI Authentication and Key Exchange for
> > the Secure Shell Protocol"
> >
> >
> > So I would like to ask the OpenSSH developers to pick up Simon's
> > GSSAPI modifications instead.
> The changes to the server to support kerberos-2 at are about 30
> lines of new code in two files.

- In my experience, that pretty much means they've got it wrong
somewhere. Using the api correctly generally requires much more
code than this. I will take a look today and try and provide
useful comments.

> Simon's code: 36 files changed, 3321 insertions(+), 9 deletions(-)
> Please consider:
>  a) kerberos-2 at can coexist with Simon's code, should it be
>     merged at some future time;
>  b) Simon's code consititutes two orders of magnitude more change
>     than what Markus committed;
>  c) not all the developers are familiar with Kerberos and GSSAPI;
>  d) Simon's code is still going through the IETF process, whereas
>     SSH.COM's is very minimal (basically a cleanup of the protocol 1
>     Kerberos support) and therefore less likely to change;

- Which was largely considered to be at best "broken" among
people knowledgeable about kerberos. Plus the k5 API is not
a standard and is subject to change, it's pretty clear to
me that it is going to have to change based on the latest
RFC for the wire protocol.

>  e) being volunteers, our time is limited; and

- Simon's code has been in use for years, looked at by
experts in the field and is generally considered the
"Right way to do this". Since your time is limited why
not take advantage of all the work that has been done
and gone through peer review, rather that a half hour

- There are lot's of people that would gladly work on
this code. In general, most people in the kerberos world
would like to drop support for telnet and krsh and move
to a standard ssh code, but we cannot do this with the
current SSH code base and nobody wants to deal with
the broken ssh1 implementation.

>  f) security problems have been caused in the past by large merges

- Kerberos security problems are almost always caused by
incorrect use of the API. For good or ill, the straightforward
approach is almost wrong, this is the reason that kerberos
communtity is trying to encourage people to use GSSAPI
( an IETF standard ) rather than the adhoc native k5 API.

- Booker C. Bense

More information about the openssh-unix-dev mailing list