openssh unix dev - May 2003 - Kerberos password auth/expiry kbdint patch

I took Markus Friedl's advice and set up a KbdintDevice for Kerberos 
password authentication/expiry. It took me a bit to wrap my head 
around privsep, but I think it's working properly (code stolen 
shamelessly from FBSD's PAM implementation :->). 

The hardest part was working out how to get the interaction 
between krb5_get_init_creds_password() (along with the prompter)
to work with the auth2_challenge routines, as the logic between the 
two are very similar. 

I ended up doing the following:

	- using a state machine and some global data to communicate 
	  between the KbdintDevice routines, krb5_g_i_c_p() and the 
	  prompter

	- rolled my own prompts, ignoring those generated by krb5_g_i_c_p()

So far, it seems to work well. My informal tests show:

	- the code (included when --with-kerberos5-kbdint is given as an
	  arg to configure) seems to interact with the existing Kerberos
	  password code with no problems

	- the password expiry works with OpenSSH versions 3.4p1, 3.5p1, 
	  and 3.6p1, SSH.com's Windows client, and putty v0.53b (apparently,
	  putty 0.52 has a problem with the kbdint routines, sending 
	  2 responses after the new password has been entered only once, 
	  causing packet_get() to bomb out on the server side)

	- the code seems to work well on Solaris and FreeBSD, but I haven't
	  yet tested it on any other platforms

Possible additions:

	- a Kerberos5ViaKbdInt option

Questions, comments, or improvements welcome.

----------------------------------------------------------------------
| Jim Hranicky, Senior SysAdmin                   UF/CISE Department |
| E314D CSE Building                            Phone (352) 392-1499 |
| jfh at cise.ufl.edu                      http://www.cise.ufl.edu/~jfh |
----------------------------------------------------------------------
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: openssh-3.6p1.krb5-kbdintdev.patch.txt
Url:
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030501/5dc7984d/attachment.txt

Is anyone interested in the patch I submitted to this list adding keyboard
interactive Kerberos support (i.e., should I submit a bugzilla report)?

If not, I can ust maintain it locally.

Thanks,

----------------------------------------------------------------------
| Jim Hranicky, Senior SysAdmin                   UF/CISE Department |
| E314D CSE Building                            Phone (352) 392-1499 |
| jfh at cise.ufl.edu                      http://www.cise.ufl.edu/~jfh |
----------------------------------------------------------------------
                          About politics:
                     Don't worry about results
                   It's the thought that counts

All good points, but let me add some others below.
  
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"
> > http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-06.txt
> >
> > 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 ssh.com are about 30
> lines of new code in two files.
> 
> Simon's code:
> 
>  36 files changed, 3321 insertions(+), 9 deletions(-)
> 
> Please consider:
> 
>  a) kerberos-2 at ssh.com can coexist with Simon's code, should it be
>     merged at some future time;
> 
      Good, at least keep this in mind.
>  b) Simon's code consititutes two orders of magnitude more change
>     than what Markus committed;
>
   Simon's code changes have been being updated for every verision of 
   OpenSSH since at least 3.0.2. (You might want to take a poll as to 
   how many sites are using it.)
 
>  c) not all the developers are familiar with Kerberos and GSSAPI;
> 
   There are other SSH products which are using the GSSAPI code,
   in particular some PC clients. We would like to see the OpenSSH 
   servers support this. Interoperability between implementations, is 
   very important. 

   GSSAPI is being used in other environments, such as SASL, and FTP.

   There are other GSSAPI implementations, other then Kerberos, such 
   as the Globus GSI which can use the same API interface.    

   The developers don't need to be very familiar with Kerberos, but rather 
   the API of the GSSAPI which has been a standard for years. And it is 
   an API.  

   There are multiple versions of Kerberos with different APIs. At least
   MIT and Hiemdal, and thier APIs do change from time to time.     

   One of the PC vendors, can even use the Microsoft SSPI which uses the
   same wire protocol as Kerberos GSSAPI, so you can run it without
   any MIT or Hiemdal code at all on the PC. 
  
>  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;
> 
      It is very close to last call, and I expect it will happen very soon. 
>  e) being volunteers, our time is limited; and
      Me too. Simon's mods are already done. 
> 
>  f) security problems have been caused in the past by large merges
>
   There may also be security questions about the SSH.COM kerberos mods.
   The way I understood it, the IETF secsh working group looked them over
   in the past and said no because of the problems, and went with the GSSAPI
   as all of the security issues are then contained in the GSS implementation. 
 
> -d
-- 

 Douglas E. Engert  <DEEngert at anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444