Bug in Kerberized telnet??

[John Hascall]

Some (better, I'd say) telnet implementations
don't initiate any telnet option processing
if you specify a (non-standard) port# so
you *can* use it to test other tcp-based
protocols.  Looks like this was doesn't
(but perhaps it has an option to do so).

John


> On Jul 6, 2004, at 11:24, Carretti Enrico wrote:
> 
> > Hi all, I'd like to submit you a problem: I've configured kerberos 
> > properly on
> > a machine; I've done all the necessary configuration and I can locally 
> > perform
> > "kerberized" telnet sessions, in fact I've replaced the UNIX daemon 
> > with the
> > kerberized one. On the same machine I've also installed Apache, 
> > becouse in my
> > plan I have to let Apache and Kerberos "talk" (with mod_auth_kerb). The
> > configuration of the web server is fine, in fact I point my browser on 
> > the
> > port 80 and I can see the default page of Apache. See that Apache and 
> > Kerberos
> > are NOT YET in communication! The problem comes now: I want to test the
> > correct installation of Apache simulating an HTTP session with telnet 
> > (using
> > the kerberized version of client and server, of course) and I perform:
> 
> I think you're a bit confused about how Kerberos authentication is 
> performed.  It's not a single specific exchange stuck on the front of 
> every application protocol.  In the Telnet protocol, there's an 
> exchange built in to say "I want to do authentication", "these are the 
> methods I support", "here's the data".  The HTTP protocol has hooks for 
> authentication too, and a way of using Kerberos within that framework, 
> but they aren't the same as for telnet.
> 
> 
> > $ telnet -a <my.machine> 80
> > GET / HTTP/1.1
> > Host: <my.machine>
> >
> > but Apache returns an error, the 501 (i.e. Method not implemented). 
> > This is
> > quite strange but comes clearer if I look to error.log, where I have
> >
> > [...] "\xff\xfb%GET / HTTP/1.0" 501 304
> >
> > This means that before GET there are some other characters ( \xff\xfb% 
> > ), as
> > you see not written by me, that make the request fail. Trying with a 
> > non
> > kerberized client to preform the same process I get a correct answer 
> > by the
> > server.
> 
> That's the telnet protocol sequence "IAC WILL AUTHENTICATE".  If it got 
> a proper telnet-protocol response saying the server supported it, it 
> might follow up with the Kerberos credentials.  But the web server 
> expects a different means to be used to incorporate the authentication 
> data from the client.
> 
> Look at the RFCs for the two protocols and you'll see each specifies 
> how to do authentication.
> 
> > Now the final question: those strange characters before GET are 
> > something like
> > the end of the stream of the negotiation with the kerberized telnet 
> > server put
> > there for error??
> 
> Close.  It's the telnet-protocol offer to do authentication.  Since the 
> server doesn't answer that offer, the authentication isn't actually 
> done.
> 
> As far as I know, you can't use telnet to test the Kerberos support in 
> Apache.  (Well, not by itself.  If you wrote a helper application to 
> get the tickets and format the authentication header to send to the 
> server, you could cut and paste it into the telnet session.)
> 
> Ken
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>