[2999] 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 16:32:39 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 20:54:43 GMT."
<199811102054.UAA29301@dcl>
Date: Tue, 10 Nov 1998 16:25:28 -0500
From: Frank Cusack <fcusack@iconnet.net>
In message <199811102054.UAA29301@dcl>,
"Theodore Y. Ts'o" writes:
>
> 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.
agreed. My problem was I didn't see where the telnet behavior
was defined. But I just looked at draft-tso-telnet-krb5-00.txt...
which has expired. What are the implications of changing this draft
to match RFC1510bis? It could even say "servers should not generate
a new subkey if they want to remain compatible with older clients"
(although I would not be in favor of such language).
In the end, my point is that I don't think it would break any *existing*
implementations. New clients would work against existing servers,
and new servers could do what they do now -- don't create a new subkey.
I didn't read the subkey negotiation as "the server MUST create a new
subkey".
If in fact, existing implementations wouldn't break, (and I don't see how
they would) AND the telnet draft could be changed, I think it's a valuable
"fix".
Anyway, that's the last I'll comment.
~frank
