[2998] in Kerberos-V5-bugs
Re: telnet/656: telnet does not check for remote subkey during authentication
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Tue Nov 10 16:03:39 1998
Date: Tue, 10 Nov 1998 20:54:43 GMT
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Frank Cusack <fcusack@iconnet.net>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, krb5-bugs@MIT.EDU, hartmans@MIT.EDU,
gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
In-Reply-To: Frank Cusack's message of Tue, 10 Nov 1998 11:09:55 -0500,
<199811101609.LAA03617@ratbert.iconnet.net>
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).
.... and the language in revisions-01 draft is changing, because it's
broken.
In all cases, though, the only thing we can do in the RFC-1510 bis draft
is specify "default behaviour" for the subkey handling, and note that
individual application or protocol specifications (like telnet, for
example) can specify something other than the default behaviour, and
that will take priority over what's in RFC-1510 bis.
We have to retain backwards compatibility with older protocols and
implementations, and that means that if RFC-1510 botched the subkey
negotiation by not specifying a standard way of doing it, we can't go in
after the fact and add a standard way if it ends up breaking the current
deployed base.
- Ted
