> tlyu> Richard Silverman <[email protected]> writes: > >> On Fri, 4 Jun 2010, Greg Hudson wrote: > >> > >>> On Fri, 2010-06-04 at 12:24 -0400, Richard E. Silverman wrote: > >>> I tracked down the bug. > >> > >> With apologies for being a pain in the butt, I'm not sure we understand > >> the situation well enough to safely make a change. > > > > Not at all; it has to be done right. > > > >> Providing zero-length input data is not the same as not providing any > >> input data. > > > > I don't understand your point here -- from a calling perspective of course > > they are distinguishable, but they *mean* the same thing, do they not? I > > mean, the AP_REQ either has application data accompanying it, or it > > doesn't. What does a null in_data pointer indicate in that regard that a > > pointer to an empty buffer doesn't (or vice versa)? > > A string of zero length is different from an absent string. Among > other things, they are encoded differently in the protocol.
In which protocol? Not Kerberos, since the application data is not a field in the AP_REQ; it's assumed to be transmitted in some application-specific way along with the AP_REQ. > >> The change you suggested could have interoperability or security > >> ramifications if an application genuinely wants to checksum the empty > >> string in an authenticator. > > > > This is a matter of the spec, isn't it? It's not a question of what an > > application *wants* to do; it's a question of what is *supposed* to be > > done when there is no application data. The RFC says of the checksum: > > > > 5.3.2. Authenticators > > ... > > cksum This field contains a checksum of the the application data > > that accompanies the KRB_AP_REQ. > > > > ... and says nothing further about how to treat the situation of no > > application data. In particular, it does not specify some special action > > to be taken in that case (e.g. a zero checksum). In the absence of that, > > I interpret it to mean that the checksum should be computed over the empty > > string in that case. And my patch assures that if krb5_mk_req_extended() > > is passed an empty buffer, it will checksum the empty string (it didn't > > before). > > The checksum field of an authenticator is an optional field. The > logical thing to do if there is no application data is to omit the > checksum field. If the application data consists of a zero-length > string, then it makes sense to checksum the zero-length string. Now that you've pointed out that the cksum is optional, I tend to agree with you, though the spec is silent on this point. However, there's difference of opinion, or at least implementation, on this. I just finished reading the Samba code (v3.3.2). In constructing the SPNEGO token, which contains an AP_REQ with no application data in sight (not an empty application data field somewhere), they do indeed pass a zero-length buffer -- not a null in_data pointer -- to krb5_mk_req_extended(). When that (logically) results in a checksum over the empty string, my NetApp filer returns KRB5KRB_AP_ERR_MODIFIED. With my modification so that this results in omitting the checksum field, the transaction succeeds. Now, since Samba is reverse-engineering a Microsoft protocol, once can argue in this case that this is a bug: they need to do what Microsoft expects. But I have identical behavior in other situations: OpenSSH to Bitvise WinSSHD, and FreeTDS to MS SQL Server. I need to review that code and see what's up. Of course, it's still a mystery to me why the server should further depend on the checksum cipher in use... I have more research to do to (hopefully) fully understand this. I'm using my patch in the meantime because it makes everything in my environment work, but it may not be the eventual right thing to do, certainly. > -- > Richard Silverman > [email protected] > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
