On Jun 4, 2010, at 14:47, Richard Silverman wrote: >> 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.
Whether an absent checksum is different from a checksum of an empty message is up to the application protocol. > What does a null in_data pointer indicate in that regard that a > pointer to an empty buffer doesn't (or vice versa)? > 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). A few lines further up, it indicates that cksum is an optional field. It might've been simpler had the spec tied, for example, an omitted checksum to omitted or zero-length application data, but the current spec allows the two cases to be different. A null pointer to the data descriptor vs a pointer to a data descriptor indicating a length of zero is how we support both. Ken -- Ken Raeburn / [email protected] / just an interested Kerberos geek :) ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
