[2997] in Kerberos-V5-bugs
Re: telnet/656: telnet does not check for remote subkey during authentication
daemon@ATHENA.MIT.EDU (Frank Cusack)
Tue Nov 10 11:23:06 1998
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU, hartmans@MIT.EDU, gnats-admin@RT-11.MIT.EDU,
krb5-prs@RT-11.MIT.EDU
In-Reply-To: Your message of "Tue, 10 Nov 1998 04:22:37 GMT."
<199811100422.EAA28913@dcl>
Date: Tue, 10 Nov 1998 11:09:55 -0500
From: Frank Cusack <fcusack@iconnet.net>
hmm... While RFC 1510 does not discuss subsession key negotiation,
the revisions-01 draft (now expired) does. Given that "no" implementations
actually have the server generate a new subkey, this patch should
be harmless, as long as telnetd continues to use the client key
(this patch does not change server behavior, only client).
In fact, if the server does generate it's own subkey, it probably
does want to use it (why else generate it?), so the existing telnet
client would not work. [Regardless of what's in RFC 1510.]
I assume that whenever a followup to 1510 comes out, it will have the
subkey negotiation discussion. So this would make telnet compliant,
and at the same time, existing implementations should work.
I can test this patch against the cybersafe and cisco telnetd's if
you like.
~frank
In message <199811100422.EAA28913@dcl>,
"Theodore Y. Ts'o" writes:
> Date: Fri, 6 Nov 1998 17:49:18 -0500 (EST)
> From: fcusack@iconnet.net
>
> >Description:
> telnet client always uses local subkey as the encryption key
> [for encrypted telnet sessions]. However, if the remote side
> sends back it's own subkey, it should use that instead. Not
> a problem against MIT telnetd, since the remote subkey is
> always identical to the local, but other telnetd's may not
> do the same thing.
> >How-To-Repeat:
> I don't know of any telnetd's that actually do this, the problem
> is not one that I have seen in actual use.
>
> I don't want to apply this patch, because to do so would imply a
> protocol change. The protocol has always been that the client could set
> the session key, but not the server. Kerberos V5 subsession key
> semantics were never defined in RFC-1510, and while I don't like how
> telnet negotiates the subsession key (if anything, it *should* be the
> server that picks the key to be used for encryption, not the client),
> changing it at this point would only cause massive interoperability
> problems.
>
> - Ted
