[663] in Kerberos_V5_Development
Re: krb5 error code numeric values -- are they architectural?
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Fri Mar 29 12:14:44 1991
Date: Fri, 29 Mar 91 12:14:05 -0500
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: sommerfeld@apollo.com
Cc: krbdev@ATHENA.MIT.EDU, raeburn@ATHENA.MIT.EDU, dce-tech@osf.org
In-Reply-To: Bill Sommerfeld's message of Thu, 28 Mar 91 17:46:27 EST,
Reply-To: tytso@ATHENA.MIT.EDU
Date: Thu, 28 Mar 91 17:46:27 EST
From: sommerfeld@apollo.com (Bill Sommerfeld)
However, there are a number of athena appliations which use comerr
codes "on the wire" (I should know, I helped write some of them before
I knew better...). If one of these is built against the DCE
implementation, it will not interoperate with one built against the
MIT version of the library.
Hmm.... what Athena applications were you referring to, specifically?
Many, if not most, of the V4 clients use the error reporting scheme in
sendauth/recvauth for the inital Kerberos exchange --- none whatsoever
--- which is bad, but never passed comerr codes "on the wire", and most
of them after that point never bothered to exchange error codes, usually
because Kerberos was only being used to authenticate the TCP connection.
Therefore, I'm not convinced how serious a problem we really have.
The V5 sendauth/recvauth will do a much better job of passing errors
back across the wire; and never fear, I was very careful about
only sending over Kerberos protocol error numbers back in the error
packet.
I think we should go with solution (1). Com_err codes can only be
guaranteed within an implementation, and applications which pass them
over the wire do so at their own peril. As far as I know, this has
always been the case; I do agree with Bill that we should explicitly
warn against it in the specs, though.
- Ted
