Kerberos Support in OpenSSH

[Joel N. Weber II]

> Just putting my 2 cents in- If you audit the code and do a good job then
> you'll probably produce some amount of output in the form of patches to
> fix potential problems and the like.

Given that for example Debian has been shipping packages with sxw's
code for a while now (well over a year, I think), at least in
unstable, I would really hope that we aren't going to see a
significant volume of patches fixing critical flaws in the code.

I think what I've been hearing from the openssh developers is that
since they have a hard time knowing that there aren't significant
security bugs, they are reluctant to merge it.  I don't think I've
ever heard anyone else expressing such concern, nor do I think I've
seen anyone claiming that there's reason to believe that there are
actual security bugs in sxw's code.

> The quality of these and possibly
> the quantity will affect what people think of your overall review/audit.
> It would probably make it easier for someone else to come through and
> review/audit if at least some of the problems have already been fixed.
>
> If you don't find any problems then your claim would probably mean less
> but there's not really much help for it I'm afraid.

I don't think anyone is very interested in knowing that something has
fewer fatal security bugs than it previously had.  What people are
interested in knowing is that there is a high degree of confidence
that there aren't security bugs.

The things I could imagine being useful might be:

1) A claim by a well-known people in the Kerberos community that
   they've looked at a particular version of the patch (with some
   known cryptographically secure checksum) and believe it to be free
   of security bugs.  Though I suspect the openssh people will still
   feel like they will be partially to blame if they accept code on
   that basis and it turns out to have security bugs.

2) A patch with detailed annotatations explaining why exactly each
   line doesn't introduce security vulnerabilities.  What I've found
   in trying to write security considerations documents or portions
   thereof in an IETF context is that if you force yourself to be very
   explicit about such things, it seems to help to force you to think
   about all the issues more clearly than you might otherwise.  It
   also increases the likelyhood that someone who's not a guru can
   look at it and start to evaluate whether there's anything that
   hasn't yet been noticed, and given that understanding these things
   is apparently hard and few people can do it, lowering the bar in
   that fashion seems to be useful.

It sounds like there's also some desire to come up with a patch that
removes the key exchange and removes the GSI support and just does
GSSAPI/krb5 userauth, so as to limit the complexity of what is being
tackled initially.