openssh unix dev - Dec 2001 - PATCH: Kerberos password authentication w/o KDC verification

Folks: We use an old AFS cell with Kerberos 4.  Our use of Kerberos 4 is 
fairly limited; we have never needed to  implement rcmd host principals 
for most of our systems.  Indeed, given that Kerberos 4 strips off the 
domain name portion of a hostname when determining the rcmd instance, we 
would not be able to do this, since we do have duplicate hostnames in 
multiple subdomains.

For AFS password authentication, OpenSSH first does Kerberos password 
authentication.  It then attempts to get a ticket for the server's rcmd 
service, in order to verify that the KDC is not being spoofed.  Of 
course, this fails if you do not have an rcmd service key.

For most of RPI's systems, those running Linux, Solaris, or AIX, this is 
not a problem.  OpenSSH uses PAM on Linux and Solaris, and AIX 
"authenticate" on AIX.  These external systems do not verify the KDC;
if
you submit a correct Kerberos/AFS password, it will grant you tickets. 
 You do not need an rcmd key.  However, our SGI Irix systems actually 
use the built-in auth-kerb4 authentication.  Since we do not have rcmd 
keys, password authentication fails.

I am sure that verifying the KDC is a good thing to do... But in our 
case, it causes difficulties.  Verifying the KDC is not consistently 
enforced, anyway.  So the attached patch provides a way to turn it off. 
 I have implemented a server configuration option, KerberosVerifyServer, 
that defaults to "yes".  If it is true, then the KDC is verified, as 
currently happens.  If it set to "no", then the behaviour I need, of
not
verifying the KDC, is provided.

 From our point of view, it would be a nice thing if this became a 
standard feature of OpenSSH.

-- 
R. Lindsay Todd                          email: toddr at rpi.edu
Senior Systems Programmer                phone: 518-276-2605
Rensselaer Polytechnic Institute         fax:   518-276-2809
Troy, NY 12180-3590                      WWW:   http://www.rpi.edu/~toddr

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-kerberos-verify-server.patch
Url:
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011214/6403445d/attachment.ksh

R. Lindsay Todd <toddr at rpi.edu> wrote on Fri, 14 Dec 2001
at 15:27:31 -0500 in <3C1A60B3.300 at rpi.edu>:
> Folks: We use an old AFS cell with Kerberos 4.  Our use of Kerberos 4 is 
> I have implemented a server configuration option, KerberosVerifyServer, 
> that defaults to "yes".  If it is true, then the KDC is verified,
as
> currently happens.  If it set to "no", then the behaviour I need,
of not
> verifying the KDC, is provided.
As a Kerberos4-specific option, this should have a Kerberos4-specifc name.
I would suggets "Kerberos4VerifyServer".

Please note that this is occasionally an issue for Kerberos 5, but there
is a krb5.conf variable (verify_ap_req_nofail) to control this.

--jhawk

On Fri, 14 Dec 2001, R. Lindsay Todd wrote:
> Folks: We use an old AFS cell with Kerberos 4.  Our use of Kerberos 4 is
> fairly limited; we have never needed to  implement rcmd host principals
> for most of our systems.  Indeed, given that Kerberos 4 strips off the
> domain name portion of a hostname when determining the rcmd instance, we
> would not be able to do this, since we do have duplicate hostnames in
> multiple subdomains.
>
> For AFS password authentication, OpenSSH first does Kerberos password
> authentication.  It then attempts to get a ticket for the server's rcmd
> service, in order to verify that the KDC is not being spoofed.  Of
> course, this fails if you do not have an rcmd service key.
>
> For most of RPI's systems, those running Linux, Solaris, or AIX, this
is
> not a problem.  OpenSSH uses PAM on Linux and Solaris, and AIX
> "authenticate" on AIX.  These external systems do not verify the
KDC; if
> you submit a correct Kerberos/AFS password, it will grant you tickets.
>  You do not need an rcmd key.  However, our SGI Irix systems actually
> use the built-in auth-kerb4 authentication.  Since we do not have rcmd
> keys, password authentication fails.
>
- I think you are confusing two things here. There's getting
a "convience" ticket and using kerberos to prove who you are.
If you don't verify the ticket using the rcmd principal and
you haven't verified the username/password via other means,
you are pretty much wide open to attack by anybody that
can inject packets into your network. Since k4 uses UDP
the attack is trivial. Any PAM module that doesn't do this
is horribly broken.

- However, if you've already verified your username/password
via the local password entry and are just getting a convience
ticket for accessing things like afs, it's a different story.

> I am sure that verifying the KDC is a good thing to do...
- It's not just a good thing to do, it's the fundamental
basis of the protocol. If you don't do it, there isn't
much difference between what you're doing and the old
rlogin /hosts.equiv file.
> But in our
> case, it causes difficulties.  Verifying the KDC is not consistently
> enforced, anyway.
- Any code that uses the tgt to grant authority, but does not verify
it by getting a service ticket and verifying the service ticket is
BROKEN. It's just the same as putting a buffer overrun or a tmp file
race condition in the code. If it's not consistently enforced, then
it should be.
> So the attached patch provides a way to turn it off.
>  I have implemented a server configuration option, KerberosVerifyServer,
> that defaults to "yes".  If it is true, then the KDC is verified,
as
> currently happens.  If it set to "no", then the behaviour I need,
of not
> verifying the KDC, is provided.
>
>  From our point of view, it would be a nice thing if this became a
> standard feature of OpenSSH.
>
- I think making this patch a "standard" feature is dubious at
best. It totally circumvents the security of the kerberos protocol.
It would be one thing if the user had already autheticated via
a local password entry, but as I understand the code there is
no guarantee that this has occurred.

- If you do include it, I suggest that you word the feature much
more perjoratively, something like.

Kerberos4UnsafeAuthentication

- You need to make it very clear that you are opening your box
wide open for the sake of convience. There was a security advisory
posted last year about exactly why this is a bad idea. I can't
seem to find the reference at the moment.

- Booker C. Bense