openssh unix dev - Nov 2001 - PAM, keyboard interactive, pam-1@ssh.com, interoperability

I have a simple goal: to use PAM to do my TIS authsrv authentications.
I have Mark Roth's pam_authsrv module -- it works fine.

+ I can configure openssh for PAM, and it works fine (negotiating ssh2
  keyboard interactive auth method).
+ I can configure ssh.com-3.0.1 for PAM, and it also works fine
  (negotiating ssh2 pam-1 at ssh.com auth method).

Unfortunately, the openssh client doesn't support pam-1 at ssh.com,
and the ssh.com client doesn't support keyboard interactive.
So I have a basic interoperability problem, and I have to choose
which vendor's universe to live in.  I don't want to!

*Sigh*

Questions:

* Does anyone have plans to incorporate pam-1 at ssh.com into openssh,
  or know of plans to incorporate keyboard-interactive into ssh.com's
  product?

* Are the openssh code maintainers open to a contribution of
  pam-1 at ssh.com support, or is this just too sore a subject for
  somebody?

* Or am I missing something -- do I have more interoperability than
  I think I do?

Liudvikas Bukys
bukys at rochester.edu

>+ I can configure openssh for PAM, and it works fine (negotiating ssh2
>  keyboard interactive auth method).
Which is the correct way to do it.
>+ I can configure ssh.com-3.0.1 for PAM, and it also works fine
>  (negotiating ssh2 pam-1 at ssh.com auth method).
This is broken, I've told SSH Inc about this, they agreed it was broken
but don't seem to have done anything about it.  There is a discussion
about this in either the openssh-unix-dev archives or the ietf-ssh archives,
I can't remeber where (I know some of it was private email to/from me
and some SSH Inc people).
>* Does anyone have plans to incorporate pam-1 at ssh.com into openssh,
>  or know of plans to incorporate keyboard-interactive into ssh.com's
>  product?
pam-1 at ssh.com should never appear in OpenSSH in my opinion.  Their design
is fundamentally flawed because if a client doesn't say it can do 
pam-1 at ssh.com as an authentication mechanism no PAM code is ever run - this
means that the user can bypass authentication policy.

In OpenSSH if password authentication is used then PAM is used as you have
noticed you can also use keyboard interactive mode to run
"non-trivial"
PAM modules.

Even in the case of using PublicKey authentication PAM account managment
functionality is still run in OpenSSH this is not the case in the versions
of SSH Inc code I have reviewed - this comes back to the fundamental flaw
in their design of requiring the client to request PAM authentication.
>* Are the openssh code maintainers open to a contribution of
>  pam-1 at ssh.com support, or is this just too sore a subject for
>  somebody?
The correct way to do this (if the design hadn't been flawed) would be
to create and IETF internet draft (and eventually RFC) so that the @ssh.com
part could be removed.  However Keyboard Interactive which already exists
as an I-D covers everything need to do PAM.
>* Or am I missing something -- do I have more interoperability than
>  I think I do?
One final point.  PAM is a server side API to allow abstraction of code
into a library to simplify applications it is not and never will be an
authentication mechanism in its own right - that ground is covered by GSS.

--
Darren J Moffat

On Wed, Nov 28, 2001 at 08:13:32AM -0500, bukys at rochester.edu
wrote:
> * Does anyone have plans to incorporate pam-1 at ssh.com into openssh,
no, it's not documented.
>   or know of plans to incorporate keyboard-interactive into ssh.com's
>   product?
i think they should :)

On Wed, 28 Nov 2001 bukys at rochester.edu wrote:
> Questions:
> 
> * Does anyone have plans to incorporate pam-1 at ssh.com into openssh,
>   or know of plans to incorporate keyboard-interactive into ssh.com's
>   product?
Why do we want to introduce a proprietary exchange into our client
to support a commercial vendor who won't implement the standard 
(kbd-interactive) way of doing such things?

-d

-- 
| By convention there is color,       \\ Damien Miller <djm at
mindrot.org>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)

> From: Damien Miller <djm at mindrot.org>
> 
> On Wed, 28 Nov 2001 bukys at rochester.edu wrote:
> 
> > Questions:
> > 
> > * Does anyone have plans to incorporate pam-1 at ssh.com into openssh,
> >   or know of plans to incorporate keyboard-interactive into
ssh.com's
> >   product?
> 
> Why do we want to introduce a proprietary exchange into our client
> to support a commercial vendor who won't implement the standard 
> (kbd-interactive) way of doing such things?
Because sometimes compromise is a good way to reach a goal.  You're 
not supporting a commercial vendor, you're supporting your users.

qf Samba et al

Carl

> From: Damien Miller <djm at mindrot.org>
> 
> On Thu, 29 Nov 2001 carl at bl.echidna.id.au wrote:
> 
> > > Why do we want to introduce a proprietary exchange into our
client
> > > to support a commercial vendor who won't implement the
standard
> > > (kbd-interactive) way of doing such things?
> > 
> > Because sometimes compromise is a good way to reach a goal. 
You're
> > not supporting a commercial vendor, you're supporting your users.
> 
> SSH.COM is not Microsoft and we are not Samba.
True :)
> The ssh.com's PAM support
> is broken anyway (cf. Darren's message) and there is a better
_standard_
> exchange for doing such things. 
Again, True.  NFS was a (arguably better) standard a long time 
before there was SMB too.  But, you're not doing Samba, and 
SSH.COM isn't Microshaft, the compromises that that team do to 
interoperate with a hostile vendor don't apply, because 
OpenSSH doesn't have to interoperate with anyone :)  Least of all
someone who was there first, and who you took the original code 
from!  Remember that SSH.COM was there first, and started the whole
thing.  
> If the users of said commerical vendor need better PAM support, they 
> should switch to OpenSSH (cf Darren's message again).
In an ideal world, sure, everyone would use OpenSSH (or FreSSH or
whatever ...).  But, this isn't an ideal world.  For the sake
of interoperability (and thus, supporting users who must live in
the real world :) ), sometimes it's ok to compromise an ideal to
reach a goal.  You don't have to, it's your baby, but you don't need
to can the idea if it's mentioned.  The strength of UNIX is that
it's flexible and can talk to anything, that's not a bad claim to
fame.  Where would we be if Eric Allman didn't make sendmail 
interact better with M$'s broken SMTP AUTH?  If Apache
insisted on only supporting "proper" HTTP?  If Mozilla only parsed 
100% legal HTML (if anyone can define that anyway?). If
your resolver library rejected A records with _'s in them?  The world's
full of these compromises.  It's how we get stuff done.  OpenSSH
is a tool to to a job.  The job is secure, authenticated
connections between computers.  If a few compromises here and 
there get made to help it interact with other vendors (broken
or otherwise), is that such a bad thing?  Unless (and even if 
it does, qf sendmail and SMTP AUTH) it breaks a security 
requirement, and even then, it could/should warn, rather than
forbid.

Carl (not wanting to start any sort of religious war, and having
made my point, not saying any more on the issue :) )

>from!  Remember that SSH.COM was there first, and started the whole
>thing.  
OpenSSH did not take SSH protocol v2 code from SSH Inc.

SSH Inc even wrote the draft for keyboard interactive that they fail to
use.

In this case they have a fundamental misunderstanding of a technology
called PAM (that Sun invented and dontated to X/Open), they have taken
PAM to be what GSS actually is, PAM is not a network protocol it is an
API. That misunderstanding has made its way into code.

The correct way to resolve this is for people who care to lobby SSH Inc
to do the correct thing, not for other implementations to introduce
security weaknesses in the their code to give the illusion of
interoperability with SSH Inc.

--
Darren J Moffat

On 28 Nov, Darren Moffat wrote:
> SSH Inc even wrote the draft for keyboard interactive that they fail
> to use.
Just to set the record straight here. I and Frank Cusack wrote the
keyboard-interactive draft and neither of us has, AFAIK, ever been
employed by SSH (Inc/OY).

That said the reason we did keyboard-interactive was just to avoid
having to add support in the client end for each new authmethod the
server chooses to implement.

	/MaF

>On 28 Nov, Darren Moffat wrote:
>> SSH Inc even wrote the draft for keyboard interactive that they fail
>> to use.
>
>Just to set the record straight here. I and Frank Cusack wrote the
>keyboard-interactive draft and neither of us has, AFAIK, ever been
>employed by SSH (Inc/OY).
Thanks, bad memory on my part I should have checked the drafts before
posting - Kevin had correctly me privately (I just hadn't got around
to sending my own correction).
>That said the reason we did keyboard-interactive was just to avoid
>having to add support in the client end for each new authmethod the
>server chooses to implement.
and thank you I think keyboard-interactive is great!

--
Darren J Moffat